1. conf or vars
join_buffer_size：一个査询 中关联多张表，可以为每个关联分配一个关联缓冲（join buffer）,所以每个査询可 能有多个关联缓冲
table_open_cache:指定了表可以被缓存的数量，而不是表可以被缓存的字节数(有些变量使用了不同的单位，所以必须知道每个变量的正确单位)
table_cache_size:设置这个变量不会立即生效一一会延迟到下次有线程打开表才有效果。当有线程打 开表时，MySQL会检査这个变量的值。
- 如果值大于缓存中的表的数量，线程可以把 最新打开的表放入缓存;
- 如果值比缓存中的表数小，MySQL将从缓存中删除不常使 用的表
DEFAULT:这个值赋给会话级变量可以把 变量改为使用全局值,把它赋值给全局变量可以设置这个变量为编译内置的默认值（不 是在配置文件中指定的值）
key_buffer_size：设置这个变量可以一次性为键缓冲区（key buffer,也叫键缓存key cache）分配所 有指定的空间。然而，操作系统不会真的立刻分配内存，而是到使用时才真正分配。
- 如果把非默认键缓 存的这个变量设置为0, MySQL将丢弃缓存在该键缓存中的索引，转而使用默认键 缓存，并且当不再有任何引用时会删除该键缓存。
- 为一个不存在的键缓存设置这个 变量，将会创建新的键缓存。
- 对一个已经存在的键缓存设置非零值，会导致刷新该 键缓存的内容。这会阻塞所有尝试访问该键缓存的操作，直到刷新操作完成。
thread_cache_size:设置这个变量不会立即生效-将在下次有连接被关闭时产生效果。当有连接被关 闭时，MySQL检查缓存中是否还有空间来缓存线程。
- 如果有空间，则缓存该线程以 备下次连接重用；
- 如果没有空间，它将销毁该线程而不再缓存。在这个场景中，缓 存中的线程数，以及线程缓存使用的内存，并不会立刻减少；只有在新的连接删除 缓存中的一个线程并使用后才会减少（MySQL只在关闭连接时才在缓存中增加线 程，只在创建新连接时才从缓存中删除线程。）
query_cache_size: 查询缓存，相同的select语句才会有效如果修改这个变量（即使 设置为与当前一样的值），MySQL会立刻删除所有缓存的査询，重新分配这片缓存 到指定大小，并且重新初始化内存。这可能花费较长的时间，在完成初始化之前服 务器都无法提供服务，因为MySQL是逐个清理缓存的查询（不建议开启）
read_rnd_buffer_size：MySQL只会在有查询需要使用时才会为该缓存分配内存，并且只会分配需要的内存 大小而不是全部指定的大小。
sort_buffer_size：MySQL只会在有査询需要做排序操作时才会为该缓存分配内存。然后，一旦需要排 序，MySQL就会立刻分配该参数指定大小的全部内存，而不管该排序是否需要这么 大的内存。当sort buffer不足以完成需要的排序时，MySQL会利用磁盘临时文件来辅助排序
innodb_max_dirty_pages_pct:如果有很 多脏页在缓冲池里，InnoDB关闭时可能会花费较长的时间，因为在关闭之前需要把脏 页写回数据文件.可以在运行时修改该变量的值改小，等待刷新线程清理缓冲池，然后在脏页数量较少时关闭mysql。
- tips:更小的innodb max dirty pages pct变量值并不保证InnoDB将在缓冲池中保持更少 的脏页。因为InnoDB默认通过一个 后台线程来刷新脏页，并且会合并写入，更高效地顺序写出到磁盘。它使得InnoDB延迟了缓冲池中刷写脏页的操作，直到 一些其他数据必须使用空间时才刷写。当脏页的百分比超过了这个阈值，InnoDB将快 速地刷写脏页，尝试让脏页的数量更低
innodb_buffer_pool_dump_at_shutdown：mysql关闭的时候是否导出innodb_buffer_pool的数据。（避免mysql重启时过久的预热时间）
innodb_buffer_pool_load_at_startup： mysql启动时是否加载innodb_buffer_pool的数据
innodb_stats_on_metadata： InnoDB在每次打开表时重新 计算统计信息，在打开之后，每隔一段过期时间或者遇到触发事件（改变表的内容或者査询 INFORMATION_SCHEMA表，等等），也会重新计算统计信息。如果有很多表，服务器可能 会花费数个小时来启动并完全预热，在这个时候服务器可能花费更多的时间在等待I/O 操作，而不是做其他事。
关闭该参数可以避免以上情况
innodb_open_files： InnoDB任意时刻 可以保持打开.ibd文件的数量。这由InnoDB存储引擎负责，而不是 MySQL服务器管理
innodb_log_file_size: 事务日志redo log每个日志文件的大小
innodb_log_files_in_group: 事务日志文件的个数限制
innodb_ concurrency_tickets：控制票据的数量，票据是按査询授权的，不是按事务。一旦査询完成，它没用完的票据就销毁了。一旦线程进入内核，它会有一定数量的“票据(Tickets)w,可以让它“免费”返回内核， 不需再做并发检査
innodb_thread_concurrency：限制一次性可以有多少线程进入 内核，0表示不限制。
max_aHowed_packet:这个设置防止服务器发送太大的包，也会控制多大的包可以被接收.如果设置得太小，有时复制上会出问题，通常 表现为备库不能接收主库发过来的复制数据
slave_net_timeout:这个选项控制备库发现跟主库的连接已经失败并且需要重连之前等待的时间。
sync_master_info, sync_relay_log, sync_relay_log_info:这些选项 使得备库崩溃后，更容易从崩溃中恢复。这些选项默认是不打开的，因为它们会导 致备库额外的fsync()操作，可能会降低性能。如果复制中出现fsyncO造成的延时问题，就应该关闭它们
innodb_autoinc_lock_mode: 这个选项控制InnoDB如何生成自增主键值，某些情况下，例如高并发插入时，自 增主键可能是个瓶颈。如果有很多事务等待自增锁(可以在SHOW ENGINE INNODB STATUS里看到)，应该审视这个变量的设置。
innodb_buffer_pool_instances:可以把缓冲池切分为多段，这是在高负载的多核机器上提升MySQL可扩展性最重要的一个方式了。多个缓冲池分 散了工作压力，所以一些全局Mutex竞争就没有那么大了
innodb_strict_mode: 这个设置让MySQL在某些条件下把警告改成抛错，尤其是无效的或者可能有风险 的CREATE TABLE选项。如果打开这个设置，就必然会检査所有CREATE TABLE选项， 因为它不会让你创建一些用起来比较爽（但是有隐患）的表。
innodb_read_io_threads 和 innodb_write_io_threads：这些选项控制有多少后台线程可以被I/O操作使用。默认 值是4个读线程和4个写线程。如果有很多硬盘并且工作负载并发很大， 可以发现这些线程很难跟上，这种情况下可以增加线程数，或者可以简单地把这个 选项的值设置为可以提供I/O能力的磁盘数量
innodb_old_blocks_time:InnoDB有个两段缓冲池LRU （最近最少使用）链表，设计目的是防止换出长期使 用很多次的页面。像mysqldump产生的这种一次性的（大）査询，通常会读取页 面到缓冲池的LRU列表，从中读取需要的行，然后移动到下一页。理论上，两段 LRU链表将阻止此页取代很长一段时间内都需要用到的页面被放入“年轻（Young）” 子链表，并且只在它已被浏览过多次后将其移动到“年老（Old）”子链表。
但是 InnoDB默认没有配置为防止这种情况，因为页内有很多行，所以从页面读取的行的 多次访问，会导致它立即被转移到“年老（Old）”子链表，对那些需要长时间缓存 ‘的页面带来换出的压力。
这个变量指定一个页面从LRU链表的“年轻”部分转移到“年老”部分之前必须经 过的毫秒数。默认情况下它设置为0,
2.status
Innodb_buffer_pool_pages_dirty：查看脏页数