甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
1）调整服务器的性能参数：key_buffer_size、Innodb_buffer_pool_size进行合理的配置
创新互联公司-专业网站定制、快速模板网站建设、高性价比盱眙网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式盱眙网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖盱眙地区。费用合理售后完善，十年实体公司更值得信赖。
2）建立合适的索引
3）写查询语句用explain分析一下执行过程，核实一下执行计划，是否按照自己的意愿执行。
索引使要注意的地方：
1)索引不会包含有NULL值的列(使用索引的列设需要置默认值)2)使用短索引 3)不要在列上进行运算，即操作符号左端（使用函数）4) like语句操作5)不使用NOT IN和操作6)复合索引的建立7)选择自己使用的索引： USE INDEX ， IGNORE INDEX ， FORCE INDEX 8) where子句中已经使用了索引的话，那么order by中的列是不会使用索引的（使用复合索引解决）
表扫描要注意的地方：
1)数据表很小，全表扫描比做索引键的查找来得快。当表的记录总数小于10且比较短时通常这么做。
2)没有合适用于 ON 或 WHERE 分句的索引字段。
3)让索引字段和常量值比较，MySQL已经计算（基于索引树）到常量覆盖了数据表的很大部分。
4)通过其他字段使用了一个基数很小（很多记录匹配索引键值）的索引键。这种情况下，MySQL认为使用索引键需要大量查找，还不如全表扫描来得更快。
5)使用合适的索引可以解决表扫描
6) 使用Limit有时候也可以解决表扫描
优化的地方太多了，一一列举不完，你可以去这里看一下，这里面关于优化的知识有很多
，如果觉得说的有用就给个好评，写这么多怪不容易的，用了我一刻钟的时间呀
mysql的优化大的有两方面：
1、配置优化
配置的优化其实包含两个方面的：操作系统内核的优化和mysql配置文件的优化
1)系统内核的优化对专用的mysql服务器来说，无非是内存实用、连接数、超时处理、TCP处理等方面的优化，根据自己的硬件配置来进行优化，这里不多讲；
2)mysql配置的优化，一般来说包含：IO处理的常用参数、最大连接数设置、缓存使用参数的设置、慢日志的参数的设置、innodb相关参数的设置等，如果有主从关系在设置主从同步的相关参数即可，网上的相关配置文件很多，大同小异，常用的设置大多修改这些差不多就够用了。
2、sql语句的优化
1） 尽量稍作计算
Mysql的作用是用来存取数据的，不是做计算的，做计算的话可以用其他方法去实现，mysql做计算是很耗资源的。
2）尽量少 join
MySQL 的优势在于简单，但这在某些方面其实也是其劣势。MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈
3）尽量少排序
排序操作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL的响应时间。
对于MySQL来说，减少排序有多种办法，比如：
通过利用索引来排序的方式进行优化
减少参与排序的记录条数
非必要不对数据进行排序
4）尽量避免 select *
在数据量少并且访问量不大的情况下，select * 没有什么影响，但是量级达到一定级别的时候，在执行效率和IO资源的使用上，还是有很大关系的，用什么字段取什么字段，减少不必要的资源浪费。
5）尽量用 join 代替子查询
虽然 Join 性能并不佳，但是和 MySQL 的子查询比起来还是有非常大的性能优势。MySQL 的子查询执行计划一直存在较大的问题，虽然这个问题已经存在多年，但是到目前已经发布的所有稳定版本中都普遍存在，一直没有太大改善。虽然官方也在很早就承认这一问题，并且承诺尽快解决，但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。
首先，数据量大的时候，应尽量避免全表扫描，应考虑在 where 及 order by 涉及的列上建立索引，建索引可以大大加快数据的检索速度。 但是，有些情况索引是不会起效的：
1、应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。
2、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3、尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
4、下面的查询也将导致全表扫描：
select id from t where name like ‘%abc%’
若要提高效率，可以考虑全文检索。
5、in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6、如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
7、应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
8、应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)=’abc’–name以abc开头的id
select id from t where datediff(day,createdate,’2005-11-30′)=0–’2005-11-30′生成的id
应改为:
select id from t where name like ‘abc%’
select id from t where createdate=’2005-11-30′ and createdate’2005-12-1′
9、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
10、在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
11、不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(…)
12、很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
优化方案：
主从同步+读写分离：
这个表在有设备条件的情况下，读写分离，这样能减少很多压力，而且数据稳定性也能提高
纵向分表：
根据原则，每个表最多不要超过5个索引，纵向拆分字段，将部分字段拆到一个新表
通常我们按以下原则进行垂直拆分:（先区分这个表中的冷热数据字段）
把不常用的字段单独放在一张表;
把text，blob等大字段拆分出来放在附表中;
经常组合查询的列放在一张表中;
缺点是：很多逻辑需要重写，带来很大的工作量。
利用表分区：
这个是推荐的一个解决方案，不会带来重写逻辑等，可以根据时间来进行表分区，相当于在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度。
横向分表：
1000W条数据不少的，会带来一些运维压力，备份的时候，单表备份所需时间会很长，所以可以根据服务器硬件条件进行水平分表，每个表有多少数据为准。
在我们使用MySQL数据库时，比较常用也是查询，包括基本查询，关联查询，条件查询等等，对于同一个操作，SQL语句的实现有很多种写法，但是不同的写法查询的性能可能会有很大的差异。这里主要介绍下select查询优化的要点。
1. 使用慢查询日志去发现慢查询。
2. 使用执行计划去判断查询是否正常运行。
3. 总是去测试你的查询看看是否他们运行在最佳状态下 –久而久之性能总会变化。
4. 避免在整个表上使用count(*),它可能锁住整张表。
5. 使查询保持一致以便后续相似的查询可以使用查询缓存。
6. 在适当的情形下使用GROUP BY而不是DISTINCT。
7. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。
8. 保持索引简单,不在多个索引中包含同一个列。
9. 有时候MySQL会使用错误的索引,对于这种情况使用USE INDEX。
10. 检查使用SQL_MODE=STRICT的问题。
11.对于记录数小于5的索引字段，在UNION的时候使用LIMIT不是是用OR.
12. 为了 避免在更新前SELECT，使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去实现。
3. 不要使用 MAX,使用索引字段和ORDER BY子句。
14. 避免使用ORDER BY RAND().
15. LIMIT M，N实际上可以减缓查询在某些情况下，有节制地使用。
16. 在WHERE子句中使用UNION代替子查询。
17. 对于UPDATES（更新），使用 SHARE MODE（共享模式），以防止独占锁。
18. 在重新启动的MySQL，记得来温暖你的数据库，以确保您的数据在内存和查询速度快。
19. 使用DROP TABLE，CREATE TABLE DELETE FROM从表中删除所有数据。
20. 最小化的数据在查询你需要的数据，使用*消耗大量的时间。
21. 考虑持久连接，而不是多个连接，以减少开销。
22. 基准查询，包括使用服务器上的负载，有时一个简单的查询可以影响其他查询。
23. 当负载增加您的服务器上，使用SHOW PROCESSLIST查看慢的和有问题的查询。
24. 在开发环境中产生的镜像数据中 测试的所有可疑的查询。
来源：PHP程序员雷雪松的博客
数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.
1. 优化一览图
2. 优化
笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.
2.1 软优化
2.1.1 查询语句优化
1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.
2.例:
显示:
其中会显示索引和查询数据读取数据条数等信息.
2.1.2 优化子查询
在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.
2.1.3 使用索引
索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者MySQL数据库索引一文,介绍比较详细,此处记录使用索引的三大注意事项:
2.1.4 分解表
对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,
2.1.5 中间表
对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.
2.1.6 增加冗余字段
类似于创建中间表,增加冗余也是为了减少连接查询.
2.1.7 分析表,,检查表,优化表
分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.
1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;
2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]
option 只对MyISAM有效,共五个参数值:
3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.
2.2 硬优化
2.2.1 硬件三件套
1.配置多核心和频率高的cpu,多核心可以执行多个线程.
2.配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.
3.配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.
2.2.2 优化数据库参数
优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.
2.2.3 分库分表
因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。另外一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。
2.2.4 缓存集群
如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
一个完整而复杂的高并发系统架构中，一定会包含：各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.