1、优先选择符合存储需要的最小的数据类型，因为存储字节越小，占用也就空间越小，性能也越好。
a.某些字符串可以转换成数字类型存储比如可以将 IP 地址转换成整型数据。
b.对于非负型的数据 (如自增 ID,整型 IP，年龄) 来说,要优先使用无符号整型来存储。
c.小数值类型（比如年龄、状态表示如 0/1）优先使用 TINYINT 类型。
2、a. 建议把 BLOB 或是 TEXT 列分离到单独的扩展表中。
如果一定要使用，建议把 BLOB 或是 TEXT 列分离到单独的扩展表中，查询时一定不要使用
select *而只需要取出必要的列，不需要 TEXT 列的数据时不要对该列进行查询。TEXT 或 BLOB 类型只能使用前缀索引
- 修改 ENUM 值需要使用 ALTER 语句；
- ENUM 类型的 ORDER BY 操作效率低，需要额外操作；
- ENUM 数据类型存在一些限制比如建议不要使用数值作为 ENUM 的枚举值。
经常会有人用字符串存储日期型的数据（不正确的做法）
- 缺点 1：无法用日期函数进行计算和比较
- 缺点 2：用字符串存储日期要占用更多的空间
索引并不是越多越好！索引可以提高效率同样可以降低效率。
索引可以增加查询效率，但同样也会降低插入和更新的效率，甚至有些情况下会降低查询效率。
因为 MySQL 优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，就会增加 MySQL 优化器生成执行计划的时间，同样会降低查询性能。
建立索引的目的是：希望通过索引进行数据查找，减少随机 IO，增加查询性能 ，索引能过滤出越少的数据，则从磁盘中读入的数据也就越少。
- 区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数）
- 尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大，IO 性能也就越好）
- 使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引）
SELECT *消耗更多的 CPU 和 IO 以网络带宽资源SELECT *无法使用覆盖索引SELECT <字段列表>可减少表结构变更带来的影响
通常子查询在 in 子句中，且子查询中为简单 SQL(不包含 union、group by、order by、limit 从句) 时,才可以把子查询转化为关联查询进行优化。
子查询性能差的原因： 子查询的结果集无法使用索引，通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大。由于子查询会产生大量的临时表也没有索引，所以会消耗过多的 CPU 和 IO 资源，产生大量的慢查询。
in 的值不要超过 500 个，in 操作可以更有效的利用索引，or 大多数情况下很少能利用到索引。
对列进行函数转换或计算时会导致无法使用索引