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.更好的做法是正确地配置基本设置（在大多数情况下，只有少数设置是重要的），并将更多的时间花在schma优化、索引和查询设计上
1.7.如果问题是由服务器的某个部分引起的，而该部分的行为可以通过配置选项进行纠正，那么可能需要对其进行更改
1.8.应该只在发现它们解决的特定性能问题时，才设置它们
1.9.如果需要改进配置，应该会在查询响应时间中体现出来
1.10.最好从查询及其响应时间开始分析，而不是从配置选项开始
1.10.1.节省很多时间，避免很多问题
2.专用数据库服务器2.1.可以设置的最佳选项是innodb_ddicatd_srvr
2.1.1.可以处理90%的性能配置
2.1.2.配置了4个额外的变量（innodb_buffr_pool_siz、innodb_log_fil_siz、innodb_log_fils_in_group和innodb_flush_mthod）
2.1.3.通常会占用50%～75%的内存
2.1.3.1.MySQL只需要少量的内存就能保持一个连接（通常是一个相关的专用线程）打开
2.2.无法使用innodb_ddicatd_srvr
2.2.1.innodb_buffr_pool_siz
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_buffr_pool_dump_at_shutdown和innodb_buffr_pool_load_at_startup这两个配置可以配合使用，以在启动时预热缓存池
2.2.2.innodb_log_fil_siz
2.2.2.1.日志文件大小
2.2.3.解决了我们所看到的绝大多数实际配置问题
2.3.应该设置一些安全选项
2.3.1.通常不会提高性能，只会避免问题
3.MySQL的配置3.1.需要永久使用的任何设置都应该写入全局配置文件，而不是在命令行中指定
3.2.将所有配置文件保存在一个地方也是一个好主意，这样可以方便地检查它们
3.3.一定要知道服务器的配置文件在哪里
3.3.1.Dbian服务器上默认不存在/tc/my.cnf，而是会在/tc/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，即使使用了SETGLOBAL来更改全局变量，它也将恢复到配置文件中的状态
3.9.3.必须同时管理MySQL的配置文件和运行时配置，并确保它们保持同步
3.10.MySQL8.0引入了一个名为持久化系统变量的新功能
3.10.1.新的语法SETPERSIST允许在运行时设置一次值，MySQL将把这个设置写入磁盘，以便在下次重启后继续使用该值
3.11.tabl_opn_cach
3.11.1.设置此变量不会立即生效：下一次线程打开表时，MySQL会检查变量的值
3.11.2.如果该值大于缓存中的表的数目，线程可以将新打开的表插入缓存
3.11.3.如果该值小于缓存中的表的数目，MySQL将从缓存中删除未使用的表
3.12.thrad_cach_siz
3.12.1.设置此变量不会立即生效：下一次关闭连接时，MySQL会检查缓存中是否有空间来存储线程
3.12.2.如果有，则缓存线程以供其他连接将来重用
3.12.3.如果没有，则将线程终止而不是缓存它
3.12.4.只有当查询需要时，MySQL才会为该缓冲区分配内存，而且会立即分配此变量指定的整块内存
3.12.5.每个处于线程缓存或休眠状态的线程通常使用大约KB内存
3.12.6.通常应该保持线程缓存足够大，这样Thrads_cratd就不会经常增加
3.13.opn_fils_limit选项
3.13.1.典型的Linux系统中，我们将其设置得尽可能大
3.13.2.在现代操作系统中，打开文件句柄的成本很低
3.13.3.如果这个设置不够大，就会看到经典的24号错误，“toomanyopnfils”
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_fil_siz和innodb_log_fils_in_group控制，这对写入性能非常重要
4.6.当缓冲区满了、事务提交时，或者每秒1次（这三个条件以先满足者为准），InnoDB会将缓冲区刷新到磁盘上的日志文件中
4.7.不需要将缓冲区设置得太大
4.7.1.建议的范围是1～8MB
4.8.innodb_flush_log_at_trx_