深入理解MySQL——配置文件常用变量说明

key_buffer_size

    设置这个变量可以一次性为键缓冲区（key buffer，也叫键缓存key cache）分配所有指定的空间。然而，操作系统不会真的立刻分配内存，而是到使用时才真正分配。例如设置键缓冲的大小为1GB，并不意味着服务器立刻分配 1GB的内存。
    MySQL 允许创建多个键缓存，这一章后面我们会探讨这个问题。如果把非默认键缓存的这个变量设置为0，MySQL 将丢弃缓存在该键缓存中的索引，转而使用默认键缓存，并日当不再有任何引用时会删除该键缓存。为一个不存在的键缓存设置这个变量，将会创建新的键缓存。对一个已经存在的键缓存设置非零值，会导致刷新该键缓存的内容。这会阻塞所有尝试访问该键缓存的操作，直到刷新操作完成。

table_cache_size

    设置这个变量不会立即生效———会延迟到下次有线程打开表才有效果。当有线程打开表时，MySQL会检查这个变量的值。如果值大于缓存中的表的数量，线程可以把最新打开的表放入缓存;如果值比缓存中的表数小，MySOL 将从缓存中删除不常使用的表。

thread_cache_size

    设置这个变量不会立即生效——将在下次有连接被关闭时产生效果。 当有连接被关闭时，MySQL 检查缓存中是否还有空间来缓存线程。如果有空间，则缓存该线程以备下次连接重用;如果没有空间，它将销毁该线程而不再缓存。在这个场景中，缓存中的线程数，以及线程缓存使用的内存，并不会立刻减少;只有在新的连接删除缓存中的一个线程并使用后才会减少。（MySQL 只在关闭连接时才在缓存中增加线程，只在创建新连接时才从缓存中删除线程。）

query_cache_size

    MySQL 在启动的时候，一次性分配并且初始化这块内存。如果修改这个变量（即使设置为与当前一样的值），MySQL 会立刻删除所有缓存的查询，重新分配这片缓存到指定大小，并且重新初始化内存。这可能花费较长的时间，在完成初始化之前服务器都无法提供服务，因为 MySQL是逐个清理缓存的查询，不是一次性全部删掉。

read_buffer_size

    MySQL 只会在有查询需要使用时才会为该缓存分配内存，并且会一次性分配该参数指定大小的全部内存。

read_rnd_buffer_size

    MySQL 只会在有查询需要使用时才会为该缓存分配内存，并且只会分配需要的内存大小而不是全部指定的大小。（max read rnd buffer size这个名字更能表达这个变量实际的含义）

sort_buffer_size

    MySQL 只会在有查询需要做排序操作时才会为该缓存分配内存。然后，一旦需要排序，MySQL 就会立刻分配该参数指定大小的全部内存，而不管该排序是否需要这么大的内存。
    我们在其他地方也对这些参数做过更多细节的说明，这里不是一个完整的列表。这里的目的只是简单地告诉大家，当修改一些常见的变量时，会有哪些期望的行为发生。
    对于连接级别的设置，不要轻易地在全局级别增加它们的值，除非确认这样做是对的。有一些缓存会一次性分配指定大小的全部内存，而不管实际上是否需要这么大，所以一个很大的全局设置可能导致浪费大量内存。更好的办法是，当查询需要时在连接级别单独调大这些值。
    最常见的例子是 sort buffer size，该参数控制排序操作的缓存大小，应该在配置文件里把它配置得小一些，然后在某些查询需要排序时，再在连接中把它调大。在分配内存后，MySQL 会执行一些初始化的工作。
    另外，即使是非常小的排序操作，排序缓存也会分配全部大小的内存，所以如果把参数设置得超过平均排序需求太多，将会浪费很多内存，增加额外的内存分配开销。许多读者认为内存分配是一个很简单的操作，听到内存分配的代价可能会很吃惊。不需要深入很多技术细节就可以讲清楚为什么内存分配也是昂贵的操作，内存分配包括了地址空间的分配，这相对来说是比较昂贵的。特别在Linux上，内存分配根据大小使用多种开销不同的策略。