备份 (backups)
监控 (moitoring)
配置 (configuration)
模式和查询 (schema and queries)
系统 (system)
其他 (other)
Backups (备份)
• 做数据库备份，在系统改变时做数据库备份例如升级前和大量改变数据之前
• 验证数据库备份的有效性，要确保你的备份可以进行数据恢复并且可用
• 备份恢复演练，定期对数据库备份进行恢复，当然建立数据库自动恢复脚本是有必要的
• 考虑开启数据库binlog日志，即使你不需要配置数据库复制功能，开启二进制日志可以做基于时间点的恢复Point-In-Time Recovery (PITR).
Monitoring (监控)
• 监控你的系统，包括操作系统，数据库实例，历史数据的监控，对历史数据的监控你可以了解过去一段时间内数据的改变
• 定期检查mysql 错误日志
• 开启mysql 慢日志并设置long_query_time捕获查询时间超过设置值的慢语句可以通过相应的工具对慢日志进行分析mysqldumpslow工具
Configuration (配置)
• 每次配置改变都要经过在测试或者工作环境（测试环境要能反应真实环境）进行验证，才能应用到正式生产环境
• 不要过度的调整配置，通常情况下默认的配置可以提供良好的初始值，根据你的需要来确定是否需要进行调整，有些参数的是难以改变的需要重启mysql实例例如innodb_buffer_pool_size，innodb_log_file_size和类似的容量设置以及设置如innodb_undo_tablespaces难以改变之后这些安装时应考虑。
在mysql 5.7.5之后支持动态改变innodb_buffer_pool_size不需要重启mysql
• 更多更大并不一定代表更好的性能例如一些配置增加他们可能造成很糟糕的性能，所以不要因为你有很多可能内存而增加设置，确保你理解你为什么要改变，并测试它是否有帮助• 一些选项需要考虑安全/事物（ACID）与性能（如sync_binlog和innodb_flush_log_at_trx_commit）。确保您了解您的系统需要什么，并相应地设置您的配置
• 一次不要改变很多配置，一次改变一个配置，这样在测试可以看到效果
• 关闭查询缓存的配置，在大多数情况下查询缓存带来很糟糕的性能，这个功能现在还比较鸡肋
• 除非有特定的原因，否则请确保MySQL 5.6和以后启用性能模式。作为起点，默认设置是好的。
Schema and Queries (模式和查询)
• 要确保每个表都要有一个主键或者不为空的唯一值
o 所有的innodb 和ndbcluster 引擎的表都要求要有主键，如果你不显式的添加主键系统内部会添加一个隐藏的主键，而隐藏的组件没有显式添加的主键工作的效率高 example InnoDB uses a global auto-increment like counter for allhidden primary key, so it more likely to become a point of contention.
o 如果在每个表上没有显式主键，则基于行的复制也会受到很大的影响。
• 当选择innodb主键时，要考虑如下
o innodb 二级索引会把主键添加进去，因此大的主键列会增加二级索引的大小
o innodb内部行排序根据主键值，这就意味着连续的主键（例如自增列）在性能要优于随机主键（例如UUID列）性能
• 多个小事物的性能优于大事物的性能，小事物可以减少锁挣用以及死锁
• 确保大字段类型的值存到数据库外的系统例如text或者blob ，诸如图像之类的数据更好地存储在文件系统中，数据库中保存有一个引用指针。
• 根据需要添加索引移除不使用的索引，索引可以更大的改善查询的性能和锁，但过多索引增加了数据库的大小，影响插入更改删除的速度
System (系统)
• 确保您正在考虑整个系统的堆栈：操作系统、MySQL、CPU、磁盘、网络、其他硬件、应用程序等。在一个地方可能出现的问题可能在是另一个问题导致的。这也意味着，如果您检测到应用程序中的查询响应时间很慢，请务必检查是否在MySQL或网络中引入了延迟等。
• 为优化I/O性能确保数据文件，二进制日志，InnoDB UNDO日志等分布在不同的物理磁盘
• 不推荐mysql 放在NFS文件系统中
Other (其他)
• 当你执行基准测试，确保工作量反映系统的实际工作量 人工的基准测试程序可能不能反映正式环境的量，在这种情况下你不能用测试结果来衡量系统。
• 阅读MySQL和操作系统的发布说明，看看是否有任何更改会影响到您或修复您遇到的bug。MySQL服务器发布说明
