MySQL大表优化方案

MySQL慢查询日志

下面优化方案参考原文地址

1、尽量不要在一开始就考虑表拆分，会带来逻辑、部署、运维的各种复杂度；
2、一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下问题不大；

注意：
1、Covering index：索引覆盖：即当索引本身包含查询所需全部数据时，不再访问数据文件本身，也就是不再需要回表操作；
2、复合索引顺序：理论上索引对顺序是敏感的，但是由于MySQL的查询优化器会自动调整where子句的条件顺序以使用适合的索引

优化

1、字段

• 尽量使用TINYINT、SMALLINT、MEDIUMINT作为整数类型，而非INT类型，如果非负加上UNSIGNED；
• VARCHAR的长度只分配真正需要的空间；
• 使用枚举或整型代替字符串类型；
• 尽量使用TIMESTAMP而非DATETIME；
• 单表不要有太多字段，建议在20以内；
• 避免使用NULL字段，很难查询优化且占用额外索引空间；
• 用整型来存IP;

2、索引

• 索引不是越多越好，要根据查询有针对性的创建，考虑在WHERE和ORDER BY涉及到的列建索引，可以根据EXPLAIN来查看是否用了索引还是全表扫描；
• 避免在WHERE子句中对字段进行NULL值判断，否则将导致全表扫描；
• 值分布稀少的字段不适合建立索引，如“性别”的这种；
• 字符字段只建立前缀索引【注意：不能用于ORDER BY和GROUP BY操作，也不能用于Covering index】，建立前缀索引：

ALTER TABLE TEST ADD INDEX `last_name4` (last_name(4));

• 字符字段最后不要做主键；
• 不用外键，由程序保证约束；
• 尽量不用UNIQUE，由程序保证约束；
• 使用多列索引时，注意顺序和查询条件一致，同时删除不必要的单利索引；

3、查询SQL

• 可通过开启慢查询日志来找到比较慢的SQL；
• 不做列运算，列运算将导致全表扫描；
• SQL语句尽可能简单：
  -- a、一条SQL只能在一个CPU运算；
  -- b、大语句拆小语句，减少锁时间；
  -- c、一条大SQL可以堵死整个库；
• 不用 SELECT * ；
• OR 改写成 IN：OR的效率是n级别，IN的效率是log(n)级别，IN的个数建议控制在200以内；
• 不用函数和触发器，在应用程序实现；
• 避免后缀式（%xxx）查询；
• 少用 JOIN ；
• 使用同类型比较：'123'跟'123'比较，123跟123比较，数字跟数字比较，字符串跟字符串比较；
• 对于连续值，使用BETWEEN，不用IN；
• 列表数据不要拿全表，要使用LIMIT分页，每页数量不要太多；