1. 除非遇到异常情况，否则不需要调整配置
1.1. 不要“调优”服务器，不要使用比率、公式或“调优脚本”作为设置配置变量的基础
1.1.1. 在互联网上搜索配置建议并不总是一个好主意，你会在博客、论坛等找到很多糟糕的建议
1.1.2. 很难判断谁是真正的专家
1.1.3. 不要相信流行的内存消耗公式
1.2. 可靠的、有信誉的MySQL服务提供商通常比简单的互联网搜索结果更安全，因为那些需要拥有满意的客户的人可能正在做正确的事情
1.2.1. 即使是他们的建议，在没有经过测试和理解的情况下进行应用也可能是危险的，因为它可能针对的是一种与你不同的情况，而你却没有理解
1.3. MySQL的不同版本会删除、弃用和更改一些选项，欲了解详细信息请查看相关文档
1.4. 应该始终通过阅读相关的官方手册来检查任何更改并仔细测试
1.5. MySQL有许多可以更改但不应该更改的设置
1.5.1. MySQL的默认设置是有充分理由的
1.5.2. 修改配置的潜在缺点可能是巨大的
1.5.3. 很多默认设置都是安全的，很多人都会直接使用。这使默认设置成为测试最彻底的设置。当没必要改变这些设置而改变它们时，可能会引起意想不到的错误
1.5.4. 节省时间和避免麻烦的好方法是使用默认设置，除非你明确知道不应该使用默认设置
1.6. 更好的做法是正确地配置基本设置（在大多数情况下，只有少数设置是重要的），并将更多的时间花在schema优化、索引和查询设计上
1.7. 如果问题是由服务器的某个部分引起的，而该部分的行为可以通过配置选项进行纠正，那么可能需要对其进行更改
1.8. 应该只在发现它们解决的特定性能问题时，才设置它们
1.9. 如果需要改进配置，应该会在查询响应时间中体现出来
1.10. 最好从查询及其响应时间开始分析，而不是从配置选项开始
1.10.1. 节省很多时间，避免很多问题
2. 专用数据库服务器
2.1. 可以设置的最佳选项是innodb_dedicated_server
2.1.1. 可以处理90%的性能配置
2.1.2. 配置了4个额外的变量（innodb_buffer_pool_size、innodb_log_file_size、innodb_log_files_in_group和innodb_flush_method）
2.1.3. 通常会占用50%～75%的内存
2.1.3.1. MySQL只需要少量的内存就能保持一个连接（通常是一个相关的专用线程）打开
2.2. 无法使用innodb_dedicated_server
2.2.1. innodb_buffer_pool_size
2.2.1.1. InnoDB缓冲池大小
2.2.1.2. 需要的内存比其他任何组件都多
2.2.1.3. 不仅缓存索引，还缓存行数据、自适应哈希索引、更改缓冲区、锁和其他内部结构等
2.2.1.4. InnoDB严重依赖缓冲池，应该确保为其分配足够的内存
2.2.1.5. 大型缓冲池会带来一些挑战，比如更长的关闭时间和预热时间
2.2.1.6. 当MySQL再次启动时，缓冲池缓存是空的，也称为冷缓存
2.2.1.7. 默认情况下，innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup这两个配置可以配合使用，以在启动时预热缓存池
2.2.2. innodb_log_file_size
2.2.2.1. 日志文件大小
2.2.3. 解决了我们所看到的绝大多数实际配置问题
2.3. 应该设置一些安全选项
2.3.1. 通常不会提高性能，只会避免问题
3. MySQL的配置
3.1. 需要永久使用的任何设置都应该写入全局配置文件，而不是在命令行中指定
3.2. 将所有配置文件保存在一个地方也是一个好主意，这样可以方便地检查它们
3.3. 一定要知道服务器的配置文件在哪里
3.3.1. Debian服务器上默认不存在/etc/my.cnf，而是会在/etc/mysql/my.cnf中查找配置
3.4. 配置文件采用标准INI格式，被分为多个部分，每个部分都以一行包含在方括号中的该部分名称开头
3.5. 配置设置全部用小写字母书写，单词之间以下画线或短横线分隔
3.5.1. 建议选择一种风格并始终如一地使用它
3.6. 全局作用域
3.7. 会话作用域
3.8. 许多会话作用域的变量都有相应的全局变量，可以将相应的全局变量的值视为会话变量的默认值
3.9. 动态配置变量
3.9.1. 很多变量（但不是全部）还可以在服务器运行时进行更改
3.9.2. 如果重新启动MySQL，即使使用了SET GLOBAL来更改全局变量，它也将恢复到配置文件中的状态
3.9.3. 必须同时管理MySQL的配置文件和运行时配置，并确保它们保持同步
3.10. MySQL 8.0引入了一个名为持久化系统变量的新功能
3.10.1. 新的语法SET PERSIST允许在运行时设置一次值，MySQL将把这个设置写入磁盘，以便在下次重启后继续使用该值
3.11. table_open_cache
3.11.1. 设置此变量不会立即生效：下一次线程打开表时，MySQL会检查变量的值
3.11.2. 如果该值大于缓存中的表的数目，线程可以将新打开的表插入缓存
3.11.3. 如果该值小于缓存中的表的数目，MySQL将从缓存中删除未使用的表
3.12. thread_cache_size
3.12.1. 设置此变量不会立即生效：下一次关闭连接时，MySQL会检查缓存中是否有空间来存储线程
3.12.2. 如果有，则缓存线程以供其他连接将来重用
3.12.3. 如果没有，则将线程终止而不是缓存它
3.12.4. 只有当查询需要时，MySQL才会为该缓冲区分配内存，而且会立即分配此变量指定的整块内存
3.12.5. 每个处于线程缓存或休眠状态的线程通常使用大约256KB内存
3.12.6. 通常应该保持线程缓存足够大，这样Threads_created就不会经常增加
3.13. open_files_limit选项
3.13.1. 典型的Linux系统中，我们将其设置得尽可能大
3.13.2. 在现代操作系统中，打开文件句柄的成本很低
3.13.3. 如果这个设置不够大，就会看到经典的24号错误，“too many openfiles”
3.14. 设置变量时要小心。并不总是越多越好
3.15. 理想情况下，应该使用版本控制系统来跟踪配置文件的更改
3.16. MySQL并不是一个严格控制内存分配的数据库服务器
3.16.1. 事实是，你不能给MySQL的内存消耗设定上限
4. I/O行为
4.1. InnoDB不仅允许你控制其恢复方式，还允许控制其打开和刷新数据的方式，这将极大地影响恢复和总体性能
4.2. InnoDB使用日志来降低提交事务的成本
4.3. InnoDB假定它使用的是传统的磁盘，随机I/O比顺序I/O的开销要大很多，因为随机I/O需要在磁盘上寻找正确的位置，并等待将所需的磁盘部分旋转到磁头下
4.4. InnoDB最终必须将更改的数据写入数据文件
4.4.1. 日志的大小固定，采取的是循环写入的方式
4.4.1.1. 当到达日志的末尾时，它会环绕到日志的开头
4.4.1.2. 如果日志记录中包含的更改尚未应用于数据文件，则无法覆盖日志记录，因为这将删除已提交事务的唯一永久记录
4.5. 日志文件的总大小由innodb_log_file_size和innodb_log_files_in_group控制，这对写入性能非常重要
4.6. 当缓冲区满了、事务提交时，或者每秒1次（这三个条件以先满足者为准），InnoDB会将缓冲区刷新到磁盘上的日志文件中
4.7. 不需要将缓冲区设置得太大
4.7.1. 建议的范围是1～8M B
4.8. innodb_flush_log_at_trx_commit
4.8.1. 1
4.8.1.1. 每次事务提交时，将日志缓冲区写入日志文件，并将其刷新到持久存储中
4.8.1.2. 默认的（也是最安全的）设置
4.8.1.3. 保证你不会丢失任何已提交的事务，除非磁盘或操作系统“假装”进行刷新操作（没有将数据真正写入磁盘）
4.8.1.3.1. 如果驱动器断电，数据仍可能丢失
4.8.2. 0
4.8.2.1. 每秒定时将日志缓冲区写入日志文件，并刷新日志文件，但在事务提交时不做任何操作
4.8.3. 2
4.8.3.1. 与0设置最重要的区别是，如果只是MySQL进程崩溃，设置为2不会丢失任何事务。但是，如果整个服务器崩溃或断电，仍然可能丢失事务
4.8.4. 设置为0和2通常会导致最多1秒的数据丢失，因为数据可能只存在于操作系统的缓存中
4.9. 高性能事务需求的最佳配置是将innodb_flush_log_at_trx_commit设置为1，并将日志文件放在具有备用电池的写缓存和SSD的RAID卷上，这既安全又非常快
4.10. 最好为日志文件和数据文件分别提供一个配置选项，但目前是组合在一起的
4.11. 如果你使用的是类UNIX操作系统，并且RAID控制器有备用电池的写缓存，我们建议使用O_DIRECT
4.12. 如果不是，则default或O_DIRECT都可能是最佳选择，具体取决于应用程序
5. InnoDB表空间
5.1. 表空间本质上是一个虚拟文件系统，由磁盘上的一个或多个文件组成
5.2. 包含了Undo日志（重新创建旧行版本所需的信息）、修改缓冲区、双写缓冲区和其他内部结构
5.3. 对日志文件也非常严格
5.4. innodb_file_per_table
5.4.1. 提供了额外的可管理性和可视性
5.4.2. 通过检查单个文件来查找表的大小要比使用SHOWTABLE STATUS快得多
5.4.3. SHOW TABLE STATUS必须执行更复杂的工作来确定为一个表分配了空间
5.4.4. 会使DROPTABLE性能变差。严重时可能导致服务器范围内明显的停顿
5.4.4.1. 先将.ibd文件链接到一个大小为零的文件，然后手动删除该文件，而不是等待MySQL来删除
5.4.4.2. 从8.0.23版本开始，这应该不再是一个问题了
5.5. 表空间在写操作频繁的环境中可能会变得非常大
5.5.1. 要限制写操作，请将innodb_max_purge_lag变量设置为0以外的值
5.5.1.1. 表示在InnoDB开始延迟更多修改数据的查询之前，可以等待清除的最大事务数
5.5.1.2. 设置innodb_max_purge_lag变量也会降低性能
5.5.2. 未清除的行版本会影响所有查询，因为它们会使表和索引变大
5.5.3. 清除线程不能跟上进度，性能就会下降
5.5.4. 默认的可重复读取事务隔离级别，InnoDB将无法删除行的旧版本，因为未提交的事务仍需要能够看到它们
5.5.5. 清除过程是多线程的，但如果遇到清除延迟问题（innodb_purge_threads和innodb_purge_batch_size），则可能需要针对工作负载进行调优
5.5.6. 如果Undo日志很大，并且表空间因此而增长，你可以强制MySQL放慢速度来让InnoDB的清理线程跟上
5.5.6.1. InnoDB会不断地写入数据并填充磁盘，直到磁盘空间耗尽或者表空间达到所定义的上限
