常用的MySQL调节和优化的提示
2013-08-28 10:38:13 
阿炯
MySQL是一个功能强大的开源数据库。随着越来越多的数据库驱动的应用程序，人们一直在推动MySQL发展到它的极限。这里是100条调节和优化MySQL安装的技巧，一些技巧是针对特定的安装环境的，但这些思路是通用的。我已经把他们分成几类，来帮助你掌握更多MySQL的调节和优化技巧。-------------------------------
MySQL 服务器硬件和操作系统调节：
1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中——在内存中访问文件时的速度要比在硬盘中访问时快的多。
2. 不惜一切代价避免使用Swap交换分区 – 交换时是从硬盘读取的，它的速度很慢。
3. 使用电池供电的RAM(注：RAM即随机存储器)。
4. 使用高级的RAID(注：Redundant Arrays of Inexpensive Disks，即磁盘阵列) – 最好是RAID10或更高。
5. 避免RAID5(注：一种存储性能、数据安全和存储成本兼顾的存储解决方案) – 确保数据库完整性的校验是要付出代价的。
6. 将操作系统和数据分区分开，不仅仅是逻辑上，还包括物理上 – 操作系统的读写操作会影响数据库的性能。
7. 把MySQL临时空间和复制日志与数据放到不同的分区 – 当数据库后台从磁盘进行读写操作时会影响数据库的性能。
8. 更多的磁盘空间等于更快的速度。
9. 更好更快的磁盘。
10. 使用SAS(注： Serial Attached SCSI，即串行连接SCSI)代替SATA(注：SATA，即串口硬盘)。
11. 较小的硬盘 比 较大的硬盘快，尤其是在RAID配置的情况下。
12. 使用电池支持的高速缓存RAID控制器。
13. 避免使用软件磁盘阵列。
14. 考虑为数据分区使用固态IO卡 (不是磁盘驱动器) – 这些卡能够为几乎任何数量的数据支持2GB/s的写入速度。
15. 在Linux中设置swappiness的值为0 – 在数据库服务器中没有理由缓存文件，这是一个服务器或台式机的优势。
16. 如果可以的话，使用 noatime 和 nodirtime 挂载文件系统 – 没有理由更新访问数据库文件的修改时间。
17. 使用 XFS 文件系统 – 一种比ext3更快、更小的文件系统，并且有许多日志选项， 而且ext3 已被证实与MySQL有双缓冲问题。
18. 调整 XFS 文件系统日志和缓冲变量 – 为了最高性能标准。
19. 在 Linux 系统中, 使用 NOOP 或者 DEADLINE IO 定时调度程序 – 同 NOOP 和 DEADLINE定时调度程序相比，这个 CFQ 和 ANTICIPATORY 定时调度程序 显得非常慢。
20. 使用64位的操作系统 – 对于MySQL，会有更大的内存支持和使用。
21. 删除服务器上未使用的安装包和守护进程 – 更少的资源占用。
22. 把使用MySQL的host和你的MySQL host放到一个hosts文件中 – 没有DNS查找。
23. 切勿强制杀死一个MySQL进程 – 你会损坏数据库和正在运行备份的程序。
24. 把服务器贡献给MySQL – 后台进程和其他服务能够缩短数据库占用CPU的时间。
-------------------------------
MySQL 配置：
25. 当写入时，使用 innodb_flush_method=O_DIRECT 来避免双缓冲。
26. 避免使用 O_DIRECT 和 EXT3 文件系统 – 你将序列化所有要写入的。
27. 分配足够的 innodb_buffer_pool_size 来加载整个 InnoDB 文件到内存中– 少从磁盘中读取。
28. 不要将 innodb_log_file_size 参数设置太大， 这样可以更快同时有更多的磁盘空间 – 丢掉多的日志通常是好的，在数据库崩溃后可以降低恢复数据库的时间。
29. 不要混用 innodb_thread_concurrency 和 thread_concurrency 参数– 这2个值是不兼容的。
30. 分配一个极小的数量给 max_connections 参数 – 太多的连接会用尽RAM并锁定MySQL服务。
31. 保持 thread_cache 在一个相对较高的数字，大约 16 – 防止打开连接时缓慢。
32. 使用skip-name-resolve参数 – 去掉 DNS 查找。
33.如果你的查询都是重复的，并且数据不常常发生变化，那么可以使用查询缓存。但是如果你的数据经常发生变化，那么使用查询缓存会让你感到失望。
34.增大temp_table_size值，以防止写入磁盘。
35.增大max_heap_table_size值，以防止写入磁盘。
36.不要把sort_buffer_size值设置的太高，否则的话你的内存将会很快耗尽。
37.根据key_read_requests和key_reads值来决定key_buffer的大小，一般情况下key_read_requests应该比key_reads值高，否则你不能高效的使用key_buffer。
38.将innodb_flush_log_at_trx_commit设置为0将会提高性能，但是如果你要保持默认值(1)的话，那么你就要确保数据的完整性，同时你也要确保复制不会滞后。
39.你要有一个测试环境，来测试你的配置，并且在不影响正常生产的情况下，可以常常进行重启。
-------------------------------
MySQL模式优化：
40. 保持你的数据库整理性。
41. 旧数据归档 - 删除多余的行返回或搜索查询。
42. 将您的数据加上索引。
43. 不要过度使用索引，比较与查询。
44. 压缩文字和BLOB数据类型 - 以节省空间和减少磁盘读取次数。
45. UTF 8和UTF16都低于latin1执行效率。
46. 有节制地使用触发器。
47. 冗余数据保持到最低限度 - 不重复不必要的数据。
48. 使用链接表，而不是扩展行。
49. 注意数据类型，在您的真实数据中，尽可能使用最小的一个。
50. 如果其他数据经常被用于查询时，而BLOB / TEXT数据不是，就把BLOB / TEXT数据从其他数据分离出来。
51.检查和经常优化表。
52. 经常重写InnoDB表优化。
53. 有时当添加列时删除索引，然后在添加回来索引，这样就会更快。
54. 针对不同的需求，使用不同的存储引擎。
55. 使用归档存储引擎日志表或审计表-这是更有效地写道。
56. 会话数据存储在缓存(memcache)的而不是MySQL中 - 缓存允许自动自动填值的，并阻止您创建难以读取和写入到MySQL的时空数据。
57.存储可变长度的字符串时使用VARCHAR而不是CHAR - 节省空间，因为固定长度的CHAR，而VARCHAR长度不固定(UTF8不受此影响)。
58. 逐步进行模式的变化 - 一个小的变化，可以有巨大的影响。
59.在开发环境中测试所有模式，反映生产变化。
60. 不要随意更改你的配置文件中的值，它可以产生灾难性的影响。
61. 有时候，在MySQL的configs少即是。
62.有疑问时使用一个通用的MySQL配置文。
-------------------------------
查询优化：
63. 使用慢查询日志去发现慢查询。
64. 使用执行计划去判断查询是否正常运行。
65. 总是去测试你的查询看看是否他们运行在最佳状态下 –久而久之性能总会变化。
66. 避免在整个表上使用count(*),它可能锁住整张表。
67. 使查询保持一致以便后续相似的查询可以使用查询缓存。
68. 在适当的情形下使用GROUP BY而不是DISTINCT。
69. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。
70. 保持索引简单,不在多个索引中包含同一个列。
71. 有时候MySQL会使用错误的索引,对于这种情况使用USE INDEX。
72. 检查使用SQL_MODE=STRICT的问题。
73. 对于记录数小于5的索引字段，在UNION的时候使用LIMIT不是是用OR。
74. 为了 避免在更新前SELECT，使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去实现。
75. 不要使用 MAX,使用索引字段和ORDER BY子句。
76. 避免使用ORDER BY RAND。
77. LIMIT M，N实际上可以减缓查询在某些情况下，有节制地使用。
78. 在WHERE子句中使用UNION代替子查询。
79. 对于UPDATES(更新)，使用 SHARE MODE(共享模式)，以防止独占锁。
80. 在重新启动的MySQL，记得来温暖你的数据库，以确保您的数据在内存和查询速度快。
81. 使用DROP TABLE，CREATE TABLE DELETE FROM从表中删除所有数据。
82. 最小化的数据在查询你需要的数据，使用*消耗大量的时间。
83. 考虑持久连接，而不是多个连接，以减少开销。
84. 基准查询，包括使用服务器上的负载，有时一个简单的查询可以影响其他查询。
85. 当负载增加您的服务器上，使用SHOW PROCESSLIST查看慢的和有问题的查询。
86. 在开发环境中产生的镜像数据中 测试的所有可疑的查询。
-------------------------------
MySQL 备份过程：
87. 从二级复制服务器上进行备份。
88. 在进行备份期间停止复制，以避免在数据依赖和外键约束上出现不一致。
89. 彻底停止MySQL，从数据库文件进行备份。
90. 如果使用 MySQL dump进行备份，请同时备份二进制日志文件 – 确保复制没有中断。
91. 不要信任LVM 快照 – 这很可能产生数据不一致，将来会给你带来麻烦。
92. 为了更容易进行单表恢复，以表为单位导出数据 – 如果数据是与其他表隔离的。
93. 当使用mysqldump时请使用 –-opt。
94. 在备份之前检查和优化表。
95. 为了更快的进行导入，在导入时临时禁用外键约束。
96. 为了更快的进行导入，在导入时临时禁用唯一性检测。
97. 在每一次备份后计算数据库，表以及索引的尺寸，以便更够监控数据尺寸的增长。
98. 通过自动调度脚本监控复制实例的错误和延迟。
99. 定期执行备份。
100. 定期测试你的备份。
-------------------------------
单机数据库优化的一些实践
1、表结构优化
在开始做一个应用的时候，数据库的表结构设计往往会影响应用后期的性能，特别是用户量上来了以后的性能。因此，表结构优化是一个很重要的步骤。
1.1、字符集
一般来说尽量选择UTF-8，虽然在存中午的时候GBK比UTF-8使用的存储空间少，但是UTF-8兼容各国语言，其实我们不必为了这点存储空间而牺牲了扩展性。事实上，后期如果要从GBK转为UTF-8所要付出的代价是很高的，需要进行数据迁移，而存储空间完全可以用花钱扩充硬盘来解决。
1.2、主键
在使用mysql的innodb的时候，innodb的底层存储模型是B+树，它使用主键作为聚簇索引，使用插入的数据作为叶子节点，通过主键可以很快找到叶子节点，从而快速获取记录。因此在设计表的时候需要增加一个主键，而且最好要自增。因为自增主键可以让插入的数据按主键顺序插入到底层的B+树的叶子节点中，由于是按序的，这种插入几乎不需要去移动已有的其它数据，所以插入效率很高。如果主键不是自增的，那么每次主键的值近似随机，这时候就有可能需要移动大量数据来保证B+树的特性，增加了不必要的开销。
1.3、字段
1.3.1、建了索引的字段必须加上not null约束，并且设置default值
1.3.2、不建议使用float、double来存小数，防止精度损失，建议使用decimal
1.3.3、不建议使用Text/blob来保存大量数据，因为对大文本的读写会造成比较大的I/O开销，同时占用mysql的缓存，高并发下会极大的降低数据库的吞吐量，建议将大文本数据保存在专门的文件存储系统中，mysql中只保存这个文件的访问地址，比如博客文章可以保存在文件中，mysql中只保存文件的相对地址。
1.3.4、varchar类型长度建议不要超过8K。
1.3.5、时间类型建议使用Datetime，不要使用timestamp，虽然Datetime占用8个字节，而timestamp只占用4个字节，但是后者要保证非空，而且后者是对时区敏感的。
1.3.6、建议表中增加gmt_create和gmt_modified两个字段，用来记录数据创建的修改时间。这两个字段建立的原因是方便查问题。
1.4、索引创建
1.4.1、这个阶段由于对业务并不了解，所以尽量不要盲目加索引，只为一些一定会用到索引的字段加普通索引。
1.4.2、创建innodb单列索引的长度不要超过767bytes，如果超过会用前255bytes作为前缀索引
1.4.3、创建innodb组合索引的各列索引长度不要超过767bytes，一共加起来不要超过3072bytes
2、SQL优化
一般来说sql就那么几种：基本的增删改查，分页查询，范围查询，模糊搜索，多表连接
2.1、基本查询
一般查询需要走索引，如果没有索引建议修改查询，把有索引的那个字段加上，如果由于业务场景没法使用这个字段，那么需要看这个查询调用量大不大，如果大，比如每天调用10W+，这就需要新增索引，如果不大，比如每天调用100+，则可以考虑保持原样。另外，select * 尽量少用，用到什么字段就在sql语句中加什么，不必要的字段就别查了，浪费I/O和内存空间。
2.2、高效分页
limit m,n其实质就是先执行limit m+n，然后从第m行取n行，这样当limit翻页越往后翻m越大，性能越低。比如
select * from FreeOA limit 100000,10，这种sql语句的性能是很差的，建议改成下面的版本:
selec id,name,age from FreeOA where id >=(select id from FreeOA limit 100000,1) limit 10
2.3、范围查询
范围查询包括between、大于、小于以及in。Mysql中的in查询的条件有数量的限制，若数量较小可以走索引查询，若数量较大，就成了全表扫描了。而between、大于、小于等，这些查询不会走索引，所以尽量放在走索引的查询条件之后。
2.4、模糊查询like
使用 like %name%这样的语句是不会走索引的，相当于全表扫描，数据量小的时候不会有太大的问题，数据量大了以后性能会下降的很厉害，建议数据量大了以后使用搜索引擎来代替这种模糊搜索，实在不行也要在模糊查询前加个能走索引的条件。
2.5、多表连接
子查询和join都可以实现在多张表之间取数据，但是子查询性能较差，建议将子查询改成join。对于mysql的join，它用的是Nested Loop Join算法，也就是通过前一个表查询的结果集去后一个表中查询，比如前一个表的结果集是100条数据，后一个表有10W数据，那么就需要在100*10W的数据集合中去过滤得到最终的结果集。因此，尽量用小结果集的表去和大表做join，同时在join的字段上建立索引，如果建不了索引，就需要设置足够大的join buffer size。如果以上的技巧都无法解决join所带来的性能下降的问题，那干脆就别用join了，将一次join查询拆分成两次简单查询。另外，多表连接尽量不要超过三张表，超过三张表一般来说性能会很差，建议拆分sql。
3、索引优化
当数据量增加到一定程度后，靠sql优化已经无法提升性能了，这时候就需要祭出大招：索引。索引有三级，一般来说掌握这三级就足够了，另外对于建立索引的字段，需要考虑其选择性。
3.1、一级索引
在where后面的条件上建立索引，单列可以建立普通索引，多列则建立组合索引。组合索引需要注意最左前缀原则。
3.2、二级索引
如果有被order by或者group by用到的字段，则可以考虑在这个字段上建索引，这样一来，由于索引天然有序，可以避免order by以及group by所带来的排序，从而提高性能。
3.3、三级索引
如果上面两招还不行，那么就把所查询的字段也加上索引，这时候就形成了所谓的索引覆盖，这样做可以减少一次I/O操作，因为mysql在查询数据的时候，是先查主键索引，然后根据主键索引去查普通索引，然后根据普通索引去查相对应的记录。如果我们所需要的记录在普通索引里都有，那就不需要第三步了。当然，这种建索引的方式比较极端，不适合一般场景。
3.4、索引的选择性
在建立索引的时候，尽量在选择性高的字段上建立。什么是选择性高呢？所谓选择性高就是通过这个字段查出来的数据量少，比如按照名字查一个人的信息，查出来的数据量一般会很少，而按照性别查则可能会把数据库一半的数据都查出来，所以，名字是一个选择性高的字段，而性别是个选择性低的字段。
4、历史数据归档
当数据量到了一年增加1000W条的时候，索引也无能为力，这时候一般的思路都是考虑分库分表。如果业务没有爆发式增长，但是数据的确在缓慢增加，则可以不考虑分库分表这种复杂的技术手段，而是进行历史数据归档。我们针对生命周期已经完结的历史数据，比如6个月之前的数据，进行归档。我们可以使用quartz的调度任务在凌晨定时将6个月之前的数据查出来，然后存入远程的hbase服务器。当然也需要提供历史数据的查询接口，以备不时之需。
-------------------------------
高性能的MySQL编写方法
一、SQL语句查询
在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。
在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。
二、SQL语句编写注意问题
下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。
1. IS NULL 与 IS NOT NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。
任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的。
2. 联接列
对于有联接的列，即使最后的联接值为一个静态值，优化器是不会使用索引的。我们一起来看一个例子，假定有一个职工表(employee)，对于一个职工的姓和名分成两列存放(FIRST_NAME和LAST_NAME)，现在要查询一个叫比尔.克林顿(Bill Cliton)的职工。
下面是一个采用联接查询的SQL语句，
select * from employss
where
first_name||''||last_name ='Beill Cliton'
上面这条语句完全可以查询出是否有Bill Cliton这个员工，但是这里需要注意，系统优化器对基于last_name创建的索引没有使用。
当采用下面这种SQL语句的编写，Oracle系统就可以采用基于last_name创建的索引。
Select * from employee
where
first_name ='Beill' and last_name ='Cliton'
遇到下面这种情况又如何处理呢？如果一个变量(name)中存放着Bill Cliton这个员工的姓名，对于这种情况我们又如何避免全程遍历，使用索引呢？可以使用一个函数，将变量name中的姓和名分开就可以了，但是有一点需要注意，这个函数是不能作用在索引列上。下面是SQL查询脚本：
select * from employee where
first_name = SUBSTR('&&name',1,INSTR('&&name',' ')-1)
and
last_name = SUBSTR('&&name',INSTR('&&name’,' ')+1)
3. 带通配符(%)的like语句
同样以上面的例子来看这种情况。目前的需求是这样的，要求在职工表中查询名字中包含cliton的人。可以采用如下的查询SQL语句：
select * from employee where last_name like '%cliton%'
这里由于通配符(%)在搜寻词首出现，所以Oracle系统不使用last_name的索引。在很多情况下可能无法避免这种情况，但是一定要心中有底，通配符如此使用会降低查询速度。然而当通配符出现在字符串其他位置时，优化器就能利用索引。在下面的查询中索引得到了使用：
select * from employee where last_name like 'c%'
4. Order by语句
ORDER BY语句决定了Oracle如何将返回的查询结果排序。Order by语句对要排序的列没有什么特别的限制，也可以将函数加入列中(象联接或者附加等)。任何在Order by语句的非索引项或者有计算表达式都将降低查询速度。
仔细检查order by语句以找出非索引项或者表达式，它们会降低性能。解决这个问题的办法就是重写order by语句以使用索引，也可以为所使用的列建立另外一个索引，同时应绝对避免在order by子句中使用表达式。
5. NOT
我们在查询时经常在where子句使用一些逻辑表达式，如大于、小于、等于以及不等于等等，也可以使用and(与)、or(或)以及not(非)。NOT可用来对任何逻辑运算符号取反。下面是一个NOT子句的例子：
... where not (status ='VALID')
如果要使用NOT，则应在取反的短语前面加上括号，并在短语前面加上NOT运算符。NOT运算符包含在另外一个逻辑运算符中，这就是不等于(<>)运算符。换句话说，即使不在查询where子句中显式地加入NOT词，NOT仍在运算符中，见下例：
... where status <>'INVALID'
再看下面这个例子：
select * from employee where salary<>3000;
对这个查询，可以改写为不使用NOT：
select * from employee where salary<3000 or salary>3000;
虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。
6. IN和EXISTS
有时候会将一列和一系列值相比较。最简单的办法就是在where子句中使用子查询。在where子句中可以使用两种格式的子查询。
第一种格式是使用IN操作符：
... where column in(select * from ... where ...);
第二种格式是使用EXIST操作符：
... where exists (select 'X' from ...where ...);
我相信绝大多数人会使用第一种格式，因为它比较容易编写，而实际上第二种格式要远比第一种格式的效率高。在Oracle中可以几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
第二种格式中，子查询以‘select 'X'开始。运用EXISTS子句不管子查询从表中抽取什么数据它只查看where子句。这样优化器就不必遍历整个表而仅根据索引就可完成工作(这里假定在where语句中使用的列存在索引)。相对于IN子句来说，EXISTS使用相连子查询，构造起来要比IN子查询困难一些。
通过使用EXIST，Oracle系统会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间。Oracle系统在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中以后再执行主查询。这也就是使用EXISTS比使用IN通常查询速度快的原因。
同时应尽可能使用NOT EXISTS来代替NOT IN，尽管二者都使用了NOT(不能使用索引而降低速度)，NOT EXISTS要比NOT IN查询效率更高。
-------------------------------
又一例MySQL性能优化
1. 简介
在Web应用程序体系架构中，数据持久层(通常是一个关系数据库)是关键的核心部分，它对系统的性能有非常重要的影响。MySQL是目前使用最多的开源数据库，但是MySQL数据库的默认设置性能非常的差，仅仅是一个玩具数据库。因此在产品中使用MySQL数据库必须进行必要的优化。
优化是一个复杂的任务，本文描述MySQL相关的数据库设计和查询优化，服务器端优化，存储引擎优化。
2. 数据库设计和查询优化
在MySQL Server性能调优中，首先要考虑的就是Database Schema设计，这一点是非常重要的。一个糟糕的Schema设计即使在性能调优的MySQL Server上运行，也会表现出很差的性能；和Schema相似，查询语句的设计也会影响MySQL的性能，应该避免写出低效的SQL查询。这一节将详细讨论这两方面的优化。
2.1 Schema Design
Schema的优化取决于将要运行什么样的query，不同的query会有不同的Schema优化方案。2.2节将介绍Query Design的优化。Schema设计同样受到预期数据集大小的影响。Schema设计时主要考虑：标准化，数据类型，索引。
2.1.1 标准化
标准化是在数据库中组织数据的过程。其中包括，根据设计规则创建表并在这些表间建立关系；通过取消冗余度与不一致相关性，该设计规则可以同时保护数据并提高数据的灵活性。通常数据库标准化是让数据库设计符合某一级别的范式，通常满足第三范式即可。也有第四范式(也称为 Boyce Codd范式，BCNF))与第五范式存在，但是在实际设计中很少考虑。忽视这些规则可能使得数据库的设计不太完美，但这不应影响功能。
标准化的特点：
1) 所有的“对象”都在它自己的table中，没有冗余。
2) 数据库通常由E-R图生成。
3) 简洁，更新属性通常只需要更新很少的记录。
4) Join操作比较耗时。
5) Select，sort优化措施比较少。
6) 适用于OLTP应用。
非标准化的特点：
1) 在一张表中存储很多数据，数据冗余。
2) 更新数据开销很大，更新一个属性可能会更新很多表，很多记录。
3) 在删除数据是有可能丢失数据。
4) Select，order有很多优化的选择。
5) 适用于DSS应用。
标准化和非标准化都有各自的优缺点，通常在一个数据库设计中可以混合使用，一部分表格标准化，一部分表格保留一些冗余数据：
1) 对OLTP使用标准化，对DSS使用非标准化
2) 使用物化视图。MySQL不直接支持该数据库特性，但是可以用MyISAM表代替。
3) 冗余一些数据在表格中，例如将ref_id和name存在同一张表中。但是要注意更新问题。
4) 对于一些简单的对象，直接使用value作为建。例如IP address等
5) Reference by PRIMARY/UNIQUE KEY。MySQL可以优化这种操作，例如：
select city_name
from city,state
where state_id=state.id and state.code=‘CA’” converted to “select city_name from city where state_id=12
2.1.2 数据类型
最基本的优化之一就是使表在磁盘上占据的空间尽可能小。这能带来性能非常大的提升，因为数据小，磁盘读入较快，并且在查询过程中表内容被处理所占用的内存更少。同时，在更小的列上建索引，索引也会占用更少的资源。可以使用下面的技术可以使表的性能更好并且使存储空间最小：
1) 使用正确合适的类型，不要将数字存储为字符串。
2) 尽可能地使用最有效(最小)的数据类型。MySQL有很多节省磁盘空间和内存的专业化类型。
3) 尽可能使用较小的整数类型使表更小。例如，MEDIUMINT经常比INT好一些，因为MEDIUMINT列使用的空间要少25%。
4) 如果可能，声明列为NOT NULL。它使任何事情更快而且每列可以节省一位。注意如果在应用程序中确实需要NULL，应该毫无疑问使用它，只是避免 默认地在所有列上有它。
5) 对于MyISAM表，如果没有任何变长列(VARCHAR、TEXT或BLOB列)，使用固定尺寸的记录格式。这比较快但是不幸地可能会浪费一些空间。即使你已经用CREATE选项让VARCHAR列ROW_FORMAT=fixed，也可以提示想使用固定长度的行。
6) 使用sample character set，例如latin1。尽量少使用utf-8，因为utf-8占用的空间是latin1的3倍。可以在不需要使用utf-8的字段上面使用latin1，例如mail，url等。
2.1.3 索引
所有MySQL列类型可以被索引，对相关列使用索引是提高SELECT操作性能的最佳途径，使用索引应该注意以下几点：
1) MySQL只会使用前缀，例如key(a, b) …where b=5 将使用不到索引。
2) 要选择性的使用索引。在变化很少的列上使用索引并不是很好，例如性别列。
3) 在Unique列上定义Unique index。
4) 避免建立使用不到的索引。
5) 在Btree index中(InnoDB使用Btree)，可以在需要排序的列上建立索引。
6) 避免重复的索引。
7) 避免在已有索引的前缀上建立索引。例如：如果存在index(a，b)则去掉index(a)。
8) 控制单个索引的长度。使用key(name(8))在数据的前面几个字符建立索引。
9) 越是短的键值越好，最好使用integer。
10) 在查询中要使用到索引(使用explain查看)，可以减少读磁盘的次数，加速读取数据。
11) 相近的键值比随机好。Auto_increment就比uuid好。
12) Optimize table可以压缩和排序index，注意不要频繁运行。
13) Analyze table可以更新数据。
2.2 Designing queries
查询语句的优化是一个Case by case的问题，不同的sql有不同的优化方案，在这里我只列出一些通用的技巧。
1) 在有index的情况下，尽量保证查询使用了正确的index。可以使用EXPLAIN select …查看结果，分析查询。
2) 查询时使用匹配的类型。例如select * from a where id=5， 如果这里id是字符类型，同时有index，这条查询则使用不到index，会做全表扫描，速度会很慢。正确的应该是 … where id=”5” ，加上引号表明类型是字符。
3) 使用--log-slow-queries –long-query-time=2查看查询比较慢的语句。然后使用explain分析查询，做出优化。
3. 服务器端优化
3.1 MySQL安装
MySQL有很多发行版本，最好使用MySQL AB发布的二进制版本。也可以下载源代码进行编译安装，但是编译器和类库的一些bug可能会使编译完成的MySQL存在潜在的问题。
如果安装MySQL的服务器使用的是Intel公司的处理器，可以使用intel c++编译的版本，在Linux World2005的一篇PPT中提到，使用intel C++编译器编译的MySQL查询速度比正常版本快30%左右。Intel c++编译版本可以在MySQL官方网站下载。
3.2 服务器设置优化
MySQL默认的设置性能很差，所以要做一些参数的调整。这一节介绍一些通用的参数调整，不涉及具体的存储引擎(主要指MyISAM，InnoDB，相关优化在4中介绍)。
--character-set：如果是单一语言使用简单的character set例如latin1。尽量少用Utf-8，utf-8占用空间较多。
--memlock：锁定MySQL只能运行在内存中，避免swapping，但是如果内存不够时有可能出现错误。
--max_allowed_packet：要足够大，以适应比较大的SQL查询，对性能没有太大影响，主要是避免出现packet错误。
--max_connections：server允许的最大连接。太大的话会出现out of memory。
--table_cache：MySQL在同一时间保持打开的table的数量。打开table开销比较大，一般设置为512。
--query_cache_size： 用于缓存查询的内存大小。
--datadir：mysql存放数据的根目录，和安装文件分开在不同的磁盘可以提高一点性能。
4. 存储引擎优化
MySQL支持不同的存储引擎，主要使用的有MyISAM和InnoDB。
4.1 MyISAM
MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默认的存储引擎，除非配置MySQL默认使用另外一个引擎。
4.1.1 MyISAM特性
4.1.1.1 MyISAM Properties
1) 不支持事务，宕机会破坏表
2) 使用较小的内存和磁盘空间
3) 基于表的锁，并发更新数据会出现严重性能问题
4) MySQL只缓存Index，数据由OS缓存
4.1.1.2 Typical MyISAM usages
1) 日志系统
2) 只读或者绝大部分是读操作的应用
3) 全表扫描
4) 批量导入数据
5) 没有事务的低并发读/写
4.1.2 MyISAM优化要点
1) 声明列为NOT NULL，可以减少磁盘存储。
2) 使用optimize table做碎片整理，回收空闲空间。注意仅仅在非常大的数据变化后运行。
3) Deleting/updating/adding大量数据的时候禁止使用index。使用ALTER TABLE t DISABLE KEYS。
4) 设置myisam_max_[extra]_sort_file_size足够大，可以显著提高repair table的速度。
4.1.3 MyISAM Table Locks
1) 避免并发insert，update。
2) 可以使用insert delayed，但是有可能丢失数据。
3) 优化查询语句。
4) 水平分区。
5) 垂直分区。
6) 如果都不起作用，使用InnoDB。
4.1.4 MyISAM Key Cache
1) 设置key_buffer_size variable。MyISAN最主要的cache设置，用于缓存MyISAM表格的index数据，该参数只对MyISAM有影响。通常在只使用MyISAM的Server中设置25-33%的内存大小。
2) 可以使用几个不同的Key Caches(对一些hot data)。
a) SET GLOBAL test.key_buffer_size=512*1024;
b) CACHE INDEX t1.i1, t2.i1, t3 IN test;
3) Preload index到Cache中可以提高查询速度。因为preloading index是顺序的，所以非常快。
a) LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES；
4.2 InnoDB
InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全(ACID兼容)存储引擎。InnoDB提供row level lock，并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中row level lock适合非常小的空间。InnoDB也支持FOREIGN KEY约束。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。
InnoDB是为在处理巨大数据量时获得最大性能而设计的，它的CPU使用效率非常高。
InnoDB存储引擎已经完全与MySQL服务器整合，InnoDB存储引擎为在内存中缓存数据和索引而维持它自己的缓冲池。 InnoDB存储它的表＆索引在一个表空间中，表空间可以包含数个文件(或原始磁盘分区)。这与MyISAM表不同，比如在MyISAM表中每个表被存在分离的文件中。InnoDB 表可以是任何大小，即使在文件尺寸被限制为2GB的操作系统上。
4.2.1 InnoDB特性
4.2.1.1 InnoDB Properties
1) 支持事务，ACID，外键。
2) Row level locks。
3) 支持不同的隔离级别。
4) 和MyISAM相比需要较多的内存和磁盘空间。
5) 没有键压缩。
6) 数据和索引都缓存在内存hash表中。
4.2.1.2 InnoDB Good For
1) 需要事务的应用。
2) 高并发的应用。
3) 自动恢复。
4) 较快速的基于主键的操作。
4.2.2 InnoDB优化要点
1) 尽量使用short，integer的主键。
2) Load/Insert数据时按主键顺序。如果数据没有按主键排序，先排序然后再进行数据库操作。
3) 在Load数据是为设置SET UNIQUE_CHECKS=0，SET FOREIGN_KEY_CHECKS=0，可以避免外键和唯一性约束检查的开销。
4) 使用prefix keys。因为InnoDB没有key压缩功能。
4.2.3 InnoDB服务器端设定
innodb_buffer_pool_size：这是InnoDB最重要的设置，对InnoDB性能有决定性的影响。默认的设置只有8M，所以默认的数据库设置下面InnoDB性能很差。在只有InnoDB存储引擎的数据库服务器上面，可以设置60-80%的内存。更精确一点，在内存容量允许的情况下面设置比InnoDB tablespaces大10%的内存大小。
innodb_data_file_path：指定表数据和索引存储的空间，可以是一个或者多个文件。最后一个数据文件必须是自动扩充的，也只有最后一个文件允许自动扩充。这样，当空间用完后，自动扩充数据文件就会自动增长(以8MB为单位)以容纳额外的数据。例如： innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:50M:autoextend两个数据文件放在不同的磁盘上。数据首先放在ibdata1中，当达到900M以后，数据就放在ibdata2中。一旦达到50MB，ibdata2将以8MB为单位自动增长。如果磁盘满了，需要在另外的磁盘上面增加一个数据文件。
innodb_autoextend_increment: 默认是8M, 如果一次insert数据量比较多的话, 可以适当增加.
innodb_data_home_dir：放置表空间数据的目录，默认在mysql的数据目录，设置到和MySQL安装文件不同的分区可以提高性能。
innodb_log_file_size：该参数决定了recovery speed。太大的话recovery就会比较慢，太小了影响查询性能，一般取256M可以兼顾性能和recovery的速度。
innodb_log_buffer_size：磁盘速度是很慢的，直接将log写道磁盘会影响InnoDB的性能，该参数设定了log buffer的大小，一般4M。如果有大的blob操作，可以适当增大。
innodb_flush_logs_at_trx_commit=2： 该参数设定了事务提交时内存中log信息的处理。
1) =1时，在每个事务提交时，日志缓冲被写到日志文件，对日志文件做到磁盘操作的刷新。Truly ACID。速度慢。
2) =2时，在每个事务提交时，日志缓冲被写到文件，但不对日志文件做到磁盘操作的刷新。只有操作系统崩溃或掉电才会删除最后一秒的事务，不然不会丢失事务。
3) =0时， 日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新。任何mysqld进程的崩溃会删除崩溃前最后一秒的事务
innodb_file_per_table：可以存储每个InnoDB表和它的索引在它自己的文件中。
transaction-isolation=READ-COMITTED: 如果应用程序可以运行在READ-COMMITED隔离级别，做此设定会有一定的性能提升。
innodb_flush_method：设置InnoDB同步IO的方式：
1) Default – 使用fsync()。
2) O_SYNC 以sync模式打开文件，通常比较慢。
3) O_DIRECT，在Linux上使用Direct IO。可以显著提高速度，特别是在RAID系统上。避免额外的数据复制和double buffering(mysql buffering 和OS buffering)。
innodb_thread_concurrency：InnoDB kernel最大的线程数。
1) 最少设置为(num_disks+num_cpus)*2。
2) 可以通过设置成1000来禁止这个限制
-------------------------------
MySQL索引和查询优化
1.索引其实就是一种归类方式，当某一个字段属性都不能归类，建立索引后是没什么效果的，或归类就二种(0和1)，且各自都数据对半分，建立索引后的效果也不怎么强。
2.主键的索引是不一样的，要区别理解。
3.当时间存储为时间戳保存的可以建立前缀索引。
4.在什么是字段上建立索引，需要根据查询条件而定，不要一上来就建立索引，浪费内存还有可能用不到。
5.大字段(blob)不要建立索引，查询也不会走索引。
6.常用建立索引的地方：
1)主键的聚集索引
2)外键索引
3)类别只有0和1就不要建索引了，没有意义，对性能没有提升，还影响写入性能
4)用模糊其实是可以走前缀索引
7.唯一索引一定要小心使用，它带有唯一约束，由于前期需求不明等情况下，可能造成我们对于唯一列的误判。
8.由于我们建立索引并想让索引能达到最高性能，这个时候我们应当充分考虑该列是否适合建立索引，可以根据列的区分度来判断，区分度太低的情况下可以不考虑建立索引，区分度越高效率越高。
SELECT COUNT(DISTINCT 列_xx)/COUNT(*) FROM 表
9.写入比较频繁的时候，不能开启MySQL的查询缓存，因为在每一次写入的时候不光要写入磁盘还的更新缓存中的数据。
10.建索引的目的：
1)加快查询速度，使用索引后查询有迹可循。
2)减少I/O操作，通过索引的路径来检索数据，不是在磁盘中随机检索。
3)消除磁盘排序，索引是排序的，走完索引就排序完成。
11.其实建索引的原理就是将磁盘I/O操作的最小化，不在磁盘中排序，而是在内存中排好序，通过排序的规则去指定磁盘读取就行，也不需要在磁盘上随机读取。
12.由于磁盘整理磁盘碎片，所有有的时候我们也可以通过建立聚集索引来减少这一类的问题。
13.当一个表中有100万数据，而经常用到的数据只有40万或40万以下，是不用考虑建立索引的，没什么性能提升。
14.什么时候不适合建立索引：
1)频繁更新的字段不适合建立索引
2)where条件中用不到的字段不适合建立索引，都用不到建立索引没有意义还浪费空间
3)表数据可以确定比较少的不需要建索引
4)数据重复且发布比较均匀的的字段不适合建索引(唯一性太差的字段不适合建立索引)，例如性别，真假值
5)参与列计算的列不适合建索引，如：
select * from table where amount+100>1000，-- 这样是不走索引的，可以改造为：select * from table where amount>1000-100。
15.使用count统计数据量的时候建议使用count(*)而不是count(列)，因为count(*)MySQL是做了优化的。
16.二次SQL查询区别不大的时候，不能按照二次执行的时间来判断优化结果，没准第一次查询后又保存缓存数据，导致第二次查询速度比第二次快，很多时候我们看到的都是假象。
17.什么时候开MySQL的查询缓存，交易系统(写多、读少)、SQL优化测试，建议关闭查询缓存，论坛文章类系统(写少、读多)，建议开启查询缓存。
18.Explain 执行计划只能解释SELECT操作。
19.查询优化可以考虑让查询走索引，走索引能提升查询速度，索引覆盖是最快的，如下就是让分页走覆盖索引提高查询速度。
Select * from fentrust e
Inner join (select fid from fentrust limit 4100000, 10) a on a.fid = e.fid
20.子查询比join快，虽然规律不绝对，但对大表多数有效
21.复杂SQL语句优化的思路：
1)首先考虑在一个表中能不能取到有关的信息，尽量少关联表
2)关联条件争取都走主键或外键查询条件，能走到对应的索引
3)争取在满足业务上走小集合数据查找
4)INNER JOIN 和子查询哪个更快，场景不一致速度也不同
22.where条件多条件一定要按照小结果集排大结果集前面
23.尽量避免大事务操作，提高系统并发能力，有时无法避免，改用定时器延迟处理。
24.什么情况不走索引：
SELECT ` famount ` FROM ` fentrust ` WHERE ` famount `+10=30;-- 不会使用索引,因为所有索引列参与了计算
SELECT `famount` FROM `fentrust` WHERE LEFT(`fcreateTime`,4) <1990; -- 不会使用索引,因为使用了函数运算,原理与上面相同
SELECT * FROM ` fuser` WHERE `floginname` LIKE‘138%' -- 走索引
SELECT * FROM ` fuser ` WHERE ` floginname ` LIKE "%7488%" -- 不走索引 -- 正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因 -- 字符串与数字比较不使用索引;
EXPLAIN SELECT * FROM `a` WHERE `a`=1 -- 不走索引
select * from fuser where floginname='xxx' or femail='xx' or fstatus=1 --如果条件中有or,即使其中有条件带索引也不会使用。换言之,就是要求使用的所有字段,都必须建立索引, 我们建议大家尽量避免使用or 关键字
25.如果MySQL估计使用全表扫描要比使用索引快，则不使用索引。
26.使用UNION ALL 替换OR多条件查询并集。
27.在大数据表删除也是一个问题，避免删除过程数据库高负载，可以考虑分配删除，一次删1000条，删完后等一会继续删除：
delete from logs where log_date <= '2012-11-01' limit 1000
28.大数据表优化：
1)建立汇总表
2)建立流水表
3)分库分表
29.建立汇总表，首先不用考虑分库分表，使用定时器定时去汇总。
30.分表，可以按水平或垂直切分。垂直分表其实就是将经常使用的数据和很少使用的数据进行垂直的切分，切分到不同的库，提高单库的数据容量，如：前3个月之前的交易记录就可以放另一个库中。
31.建立流水表，数据冗余，有这个表记录流水变更就不用去写复杂SQL计算流水。
32.分库，多数据库相同库结构，分发处理并发能力，但同时带来了数据同步问题，也可以使用分库做主备分离。
32.SQL优化顺序：
1)尽量少作计算
2)尽量少 join
3)尽量少排序
4)尽量避免 select *
5)尽量用 join 代替子查询
6)尽量少 or
7)尽量用 union all 代替 union
8)尽量早过滤
9)避免类型转换
10)优先优化高并发的 SQL，而不是执行频率低某些"大"SQL
11)从全局出发优化，而不是片面调整
12)尽可能对每一条运行在数据库中的SQL进行 Explain
33.如下是30条大数据表优化要点：
1)对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2)应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=0
3)应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。
4)应尽量避免在 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
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)下面的查询也将导致全表扫描：select id from t where name like '李%' 若要提高效率，可以考虑全文检索。
7)如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：select id from t where num=@num可以改为强制查询使用索引：select id from t with(index(索引名)) where num=@num
8)应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where num/2=100应改为:select id from t where num=100*2
9)应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where substring(name,1,3)='abc' ，name以abc开头的id 应改为: select id from t where name like 'abc%'
10)不要在 where 子句中的"="左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11)在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12)不要写一些没有意义的查询，如需要生成一个空表结构：select col1,col2 into #t from t where 1=0 这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样： create table #t(...)
13)很多时候用 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)
14)并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15)索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16)应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17)尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18)尽可能的使用 varchar/nvarchar 代替 char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19)任何地方都不要使用 select * from t ，用具体的字段列表代替"*"，不要返回用不到的任何字段。
20)尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限(只有主键索引)。
21)避免频繁创建和删除临时表，以减少系统表资源的消耗。
22)临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23)在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24)如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25)尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26)使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27)与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括"合计"的例程通常要比使用游标执行的速度快。如果开发时 间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28)在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC 消息。
29)尽量避免大事务操作，提高系统并发能力。
30)尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
该文章最后由 阿炯 于 2018-07-11 10:59:47 更新，目前是第 2 版。