下面优化方案参考原文地址
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分页，每页数量不要太多；
网友评论