Mysql数据库优化

to be add...

---------------------------------------------------------------------------------------------------------------------

前辈文章原址

http://blog.chinaunix.net/uid-20639775-id-3154234.html

说明：本文的环境为CENTOS 5.5 64 Bit /Mysql 5.1.50

简介：使用Mysql有一段时间了，期间做了不少关于Mysql优化、设计、维护的工作，这两天有时间做一下简单的总结，方便自己回忆，同时也希望能对大家有点帮助.

I            硬件配置优化

• CPU选择：多核的CPU，主频高的CPU
• 内存：更大的内存
• 磁盘选择：更快的转速、RAID、阵列卡，
• 网络环境选择：尽量部署在局域网、SCI、光缆、千兆网、双网线提供冗余、0.0.0.0多端口绑定监听

II         操作系统级优化

• 使用64位的操作系统，更好的使用大内存。
• 设置noatime,nodiratime

[zhangxy@dowload_server1 ~]$ cat /etc/fstab

• 优化内核参数

• 加大文件描述符限制

Vim /etc/security/limits.conf

加上

• 文件系统选择 xfs

III      Mysql设计优化
III.1存储引擎的选择

• Myisam：数据库并发不大，读多写少,而且都能很好的用到索引，sql语句比较简单的应用，TB数据仓库
• Innodb：并发访问大，写操作比较多，有外键、事务等需求的应用，系统内存较大。

III.2命名规则

• 多数开发语言命名规则：比如MyAdress
• 多数开源思想命名规则：my_address
• 避免随便命名

III.3字段类型选择

字段类型的选择的一般原则：

• 根据需求选择合适的字段类型，在满足需求的情况下字段类型尽可能小。
• 只分配满足需求的最小字符数，不要太慷慨。

原因：更小的字段类型更小的字符数占用更少的内存，占用更少的磁盘空间，占用更少的磁盘IO，以及占用更少的带宽。

III.3.1  整型：

见如下图:

根据满足需求的最小整数为选择原则，能用INT的就不要用BIGINT。

用无符号INT存储IP，而非CHAR(15)。

III.3.2  浮点型：

III.3.3  时间类型

III.3.4  字符类型

注：L表示可变长度的意思

对于varchar和char的选择要根据引擎和具体情况的不同来选择，主要依据如下原则:

1. 如果列数据项的大小一致或者相差不大，则使用char。
2. 如果列数据项的大小差异相当大，则使用varchar。
3. 对于MyISAM表，尽量使用Char，对于那些经常需要修改而容易形成碎片的myisam和isam数据表就更是如此，它的缺点就是占用磁盘空间。
4. 对于InnoDB表，因为它的数据行内部存储格式对固定长度的数据行和可变长度的数据行不加区分（所有数据行共用一个表头部分，这个标头部分存放着指向各有关数据列的指针），所以使用char类型不见得会比使用varchar类型好。事实上，因为char类型通常要比varchar类型占用更多的空 间，所以从减少空间占用量和减少磁盘i/o的角度，使用varchar类型反而更有利。
5. 表中只要存在一个varchar类型的字段，那么所有的char字段都会自动变成varchar类型，因此建议定长和变长的数据分开。

III.4编码选择

单字节 latin1

多字节 utf8(汉字占3个字节，英文字母占用一个字节)

如果含有中文字符的话最好都统一采用utf8类型，避免乱码的情况发生。

III.5主键选择原则

注：这里说的主键设计主要是针对INNODB引擎

1. 能唯一的表示行。
2. 显式的定义一个数值类型自增字段的主键，这个字段可以仅用于做主键，不做其他用途。
3. MySQL主键应该是单列的，以便提高连接和筛选操作的效率。
4. 主键字段类型尽可能小，能用SMALLINT就不用INT，能用INT就不用BIGINT。
5. 尽量保证不对主键字段进行更新修改，防止主键字段发生变化，引发数据存储碎片，降低IO性能。
6. MySQL主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
7. MySQL主键应当有计算机自动生成。
8. 主键字段放在数据表的第一顺序。

推荐采用数值类型做主键并采用auto_increment属性让其自动增长。

III.6其他需要注意的地方

• NULL OR NOT NULL

尽可能设置每个字段为NOT NULL，除非有特殊的需求，原因如下：

1. 使用含有NULL列做索引的话会占用更多的磁盘空间，因为索引NULL列需要而外的空间来保存。
2. 进行比较的时候，程序会更复杂。
3. 含有NULL的列比较特殊，SQL难优化，如果是一个组合索引，那么这个NULL 类型的字段会极大影响整个索引的效率。

• 索引

索引的缺点：极大地加速了查询，减少扫描和锁定的数据行数。

索引的缺点：占用磁盘空间，减慢了数据更新速度，增加了磁盘IO。

添加索引有如下原则：

1. 选择唯一性索引。
2. 为经常需要排序、分组和联合操作的字段建立索引。
3. 为常作为查询条件的字段建立索引。
4. 限制索引的数据，索引不是越多越好。
5. 尽量使用数据量少的索引，对于大字段可以考虑前缀索引。
6. 删除不再使用或者很少使用的索引。
7. 结合核心SQL优先考虑覆盖索引。
8. 忌用字符串做主键。

• 反范式设计

适当的使用冗余的反范式设计，以空间换时间有的时候会很高效。

IV     Mysql软件优化

• 开启mysql复制，实现读写分离、负载均衡，将读的负载分摊到多个从服务器上，提高服务器的处理能力。
• 使用推荐的GA版本，提升性能
• 利用分区新功能进行大数据的数据拆分

V        Mysql配置优化

注意：全局参数一经设置，随服务器启动预占用资源。

• key_buffer_size参数

mysql索引缓冲，如果是采用myisam的话要重点设置这个参数，根据（key_reads/key_read_requests）判断

• innodb_buffer_pool_size参数

INNODB 数据、索引、日志缓冲最重要的引擎参数，根据（hit riatos和FILE I/O）判断

• wait_time_out参数

线程连接的超时时间，尽量不要设置很大，推荐10s

• max_connections参数

服务器允许的最大连接数，尽量不要设置太大，因为设置太大的话容易导致内存溢出，需要通过如下公式来确定：

• thread_concurrency参数

线程并发利用数量，(cpu+disk)*2,根据(os中显示的请求队列和tickets)判断

• sort_buffer_size参数

获得更快的--ORDER BY,GROUP BY,SELECT DISTINCT,UNION DISTINCT

• read_rnd_buffer_size参数

当根据键进行分类操作时获得更快的--ORDER BY

• join_buffer_size参数

join连接使用全表扫描连接的缓冲大小，根据select_full_join判断

• read_buffer_size参数

全表扫描时为查询预留的缓冲大小，根据select_scan判断

• tmp_table_size参数

临时内存表的设置，如果超过设置就会转化成磁盘表，根据参数(created_tmp_disk_tables)判断

• innodb_log_file_size参数(默认5M)

记录INNODB引擎的redo log文件，设置较大的值意味着较长的恢复时间。

• innodb_flush_method参数(默认fdatasync)

Linux系统可以使用O_DIRECT处理数据文件，避免OS级别的cache，O_DIRECT模式提高数据文件和日志文件的IO提交性能

• innodb_flush_log_at_trx_commit(默认1)

1. 0表示每秒进行一次log写入cache，并flush log到磁盘。
2. 1表示在每次事务提交后执行log写入cache，并flush log到磁盘。
3. 2表示在每次事务提交后，执行log数据写入到cache，每秒执行一次flush log到磁盘。

VI     Mysql语句级优化

1. 性能查的读语句，在innodb中统计行数,建议另外弄一张统计表，采用myisam，定期做统计.一般的对统计的数据不会要求太精准的情况下适用。
2. 尽量不要在数据库中做运算。
3. 避免负向查询和%前缀模糊查询。
4. 不在索引列做运算或者使用函数。
5. 不要在生产环境程序中使用select * from 的形式查询数据。只查询需要使用的列。
6. 查询尽可能使用limit减少返回的行数，减少数据传输时间和带宽浪费。
7. where子句尽可能对查询列使用函数，因为对查询列使用函数用不到索引。
8. 避免隐式类型转换，例如字符型一定要用’’，数字型一定不要使用’’。
9. 所有的SQL关键词用大写，养成良好的习惯，避免SQL语句重复编译造成系统资源的浪费。
10. 联表查询的时候，记得把小结果集放在前面，遵循小结果集驱动大结果集的原则。
11. 开启慢查询，定期用explain优化慢查询中的SQL语句。