目录

本文总结一些MySQL的最佳实践案例

纸上谈兵

  1. 范式：
    • 第一范式：当关系模式R的所有属性都不能再分解为更基本的数据单位时，称R是满足第一范式，即属性不可分
    • 第二范式：关系模式R满足第一范式，并且R的所有非主属性都完全函数依赖于R的每一个候选码，称R满足第二范式（不存在部分函数依赖）
    • 第三范式：关系模式R满足第一范式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选码，称R满足第三范式，即非主属性不传递依赖于候选码。
    • BCNF范式：关系模式R满足第一范式。若R中的所有非平凡函数依赖X→Y（Y不包含于X）的左部都包含R的任一候选键，则R∈BCNF。换言之，BCNF中的所有依赖的左部都必须包含候选码。（任何属性不能依赖于非候选码）

建库建表

  1. 默认使用InnoDB、mb4utf8字符集
  2. 不使用触发器等拖累MySQL计算资源的特性
    • 可以交给具体业务维护

查询

  1. 不负向查询：not
  2. 不模糊查询：like
  3. 不允许where子句使用函数、表达式处理查询到的字段值，非要使用则必须慎重
    • 可以对常量使用
  4. 不select *
  5. 多分片并带分片键进行查询
  6. 不用大表join
  7. 合理使用索引、注意联合索引的传入顺序
  8. 不要给经常更新的字段添加索引
  9. 拆表，减少单个超大表
  10. 在够用的前提下，使用更小的数据类型
  11. 避免NULL，尽量加上默认值，NULL对索引和查询优化的表现都很差
  12. 仔细检查类型不一致问题
  13. 数据库负载很重的情况下，不在SQL中做业务，简单查询后，返回给业务层，由业务代码进行数据处理

优化

  1. 索引：
    • 原则：最适合索引的列是出现在WHERE子句中的列，或连接子句中指定的列，而不是出现在SELECT关键字后的选择列表中的列。
  2. 说在前面：
    • 设计：对于数据库，在设计之初就应该进行优化方面的估计和考虑，尽量避免糟糕的库、表设计。
    • 优化：优化没有放诸四海皆准的条陈，可以从一定程度上思考MySQL的执行方式，再结合数据特点、查询特点进行优化。
    • 优化思路：使用EXPLAIN、SHOW WARNINGS等工具，查看执行计划，分析MySQL引擎做的工作，并如何避免一些低效事情的发生
  3. 垂直拆分的一些思路：
    1. 把不常用的一些列单独放到附表
    2. 经常组合查询的列放到一起
    3. 把text、blob等大字段拆分出来放到单独的表中
  4. 水平拆分
  5. 其他方案：
    1. 对于超大量的数据，可能MySQL并没有办法提供好方案，这个时候可以看看NoSQL等其他数据存储方案

参考

  1. 实践中如何优化MySQL（精）
  2. 详解第一范式、第二范式、第三范式、BCNF范式
  3. 数据库基础（3）函数依赖-平凡依赖，完全依赖，部分依赖，传递依赖
  4. 什么是码，主码，主属性，非主属性