优化服务器设置

高级InnoDB设置

innodb_old_blocks_time

InnoDB有两段缓冲池LRU(最近最少使用)链表，设计目的是防止换出长期很多次的页面。像mysqldump产生的这种一次性的(大)查询，通常会读取页面到缓冲池的LRU列表，从中读取需要的行，然后移动到下一页。理论上，两段LRU链表将阻止此页取代很长一段时间内都需要用到的页面被放入"年轻(Young)"子链表，并且只在它被已被浏览过多次后将其移动到"年老(Old)"子链表。但是InnoDB默认没有配置为防止这种情况，因为页内有很多行，所以从页面读取的行的多次访问，会导致它立即被转移到"年老(Old)"子链表，对哪些需要长时间缓存的页面带来换出的压力。这个变量指定一个页面从LRU链表的"年轻"部分转移到"年老"部分之前必须经过的毫秒数。默认情况下将它设置为0，将它设为诸如1000毫秒(一秒)这样的小一点的值，在基准测试中已被证明非常有效。

线程

MySQL每个连接使用一个线程，另外还有一个内部处理线程、特殊用途的线程，以及所有存储引擎创建的线程。在MySQL5.5中，Oracle提供了一个线程池插件，但目前尚不清楚在实际应用中能获得什么好处。无论哪种方式，MySQL都需要大量的线程才能有效地工作。MySQL确实需要内核级线程地支持，而不只是用户级线程，这样才能更有效地使用多个CPU.另外也需要有效的同步原子，例如互斥变量。操作系统的线程库必须提供所有的这些功能。
GNU/Linux提供两个线程库:LinuxThreads和新的原生POSIX线程库(NPTL).LinuxThreads在某些情况下仍然使用，但现在的发行版已经切换到NPTL，并且大部分应用已经不再加载LinuxThreads.NPTL更轻量，更高效，也不会有哪些LinuxThreads遇到的问题。
FreeBSD会加载许多线程库。从历史上看，它对县城的支持很弱，但现在已经宾得好多了，在一些测试中，甚至由于SMP系统上的GNU/Linux。在FreeBSD6和更新版本，土建的线程库是libthr,早期版本使用的linuxthreads,是FreeBSD从GNU/Linux上一致的Linux/Threads库。
通常，线程问题都是过去的事了，现在GNU/Linux和FreeBSD都提供了很好的线程库，Solaris和Windows一直对线程有很好的支持，尽管直到5.5发布之前，MyISAM都不能在Windows下很好地使用线程，但5.5里有显著的提升

内存交换区

当操作系统因为没有足够的内存而将一些虚拟内存写到磁盘就会发生内存交换(内存交换有时称为页面交换，从技术上来说，它们是不同的东西，但是人么你通常把它们作为同义词)内存交换对操作系统中运行的进程是透明的。只有操作系统知道特定的虚拟内存地址是在物理内存还是硬盘。
内存交换对MySQL性能影响是很糟糕的，它破坏了缓存在内存的目的，并且相对于使用很小的内存做缓存，使用交换区的性能更差。MySQL和存储引擎有很多算法来区别对待内存中的数据和硬盘上的数据，因为一般都假设内存数据访问代价更低。
因为内存交换对用户进程不可见，MySQL(或存储引擎)并不知道数据实际上已经移动到磁盘，还会以为在内存中。
结果会导致很差的性能。例如，若存储引擎认为数据依然在内存，可能觉得为"短暂"的内存操作锁定一个全局互斥变量(例如InnoDB缓冲池Mutex)是OK的。如果这个操作实际上引起了硬盘IO,直到IO操作完成前任何操作都会被挂起。这意味着内存交换比直接做硬盘IO操作还要糟糕。
在GNU/Linux上，可以用vmstat来监控内存交换。最好查看si和so列报告的内存交换IO活动，这比看swap列报告的交换区利用率更重要。swapd列可以展示那些被载入了但是没有被使用的进程，它们并不是真的会称为问题。我们喜欢si和so列的值为0，并且一定要保证它们低于每秒10个块。
极端的场景下，太多的内存交换可能导致操作系统交换空间溢出。如果发生了这种情况，缺乏虚拟内存可能让MySQL崩溃。但是即使交换空间没有移除，非常活跃的内存交换也会导致整个操作变得无法响应，到这种时候甚至不能登录系统去杀掉MySQL进程。有时当交换空间溢出时，甚至Linux内核都会完全Hang住。绝不要让系统的虚拟内存溢出！对交换空间利用率做好监控和报警。如果不知道需要多少交换空间，就在硬盘上尽可能多地分配空间，这不会对性能造成冲击，只是消耗了硬盘空间。有些大的组织清楚地直到内存消耗将有多大，并且内存交换被非常严格地控制，但是对于只有少量多用途的MySQL实例，并且工作负载页多种多样的环境，通常不切实际。如果后者的描述更符合实际情况，确认给服务器一些"呼吸"的空间，分配足够的交换空间。
在特别大的内存压力下经常发生的另一件事是内存不足(OOM)，这会导致踢掉和杀掉一些进程。在MySQ进程这很常见。在另外的进程上也挺常见，比如SSH，甚至会让系统不能从网络访问。可以通过设置SSH进程的oom_adj或oom_score_adj值来避免这种情况。
可以通过正确地配置MySQL缓冲来解决大部分内存交换问题，但是有时候操作系统的虚拟内存系统还是会决定交换MySQL的内存。这通常发生在操作系统看到MySQL发出了大量的IO,因此尝试增加文件缓存来保存更多数据时。如果没有足够的内存，有些东西就必须交换出去，有些可能就是MySQL本身。有些老的Linux内核版本也有一些适得其反鞥多优先级，导致本不应该被交换的被交换出去，但是在最近的内核都被缓解了。
有些人主张完全禁用交换文件。尽管这样做有时在某些内核拒绝工作的极端场景下是可行的，但这降低了操作系统的性能(在理论上不会，但是实际上会的)。同时这样做也是很危险的，因为禁用内存交换就相当于给虚拟内存设置了一个不可动摇的限制。如果MySQL需要临时使用很大一块内存，或者有很耗内存的进程运行在同一台机器(如夜间批量任务)，MySQL会内存溢出、崩溃或者被操作系统杀死。
操作系统通常允许对虚拟内存和IO进行一些限制。我们提供过一些GNU/Linux上控制它们的办法。最基本的办法是修改/proc/sys/vm/swappiness为一个很小的值，例如0或1.这告诉内核除非虚拟内存完全满了，否则不要使用交换区。下面如何检查这个值的例子。这个值显示为0，这是默认的设置(范围是0~100),如果它不是0，则对服务器而言这是一个跟糟糕的默认值，服务器应该设置为0:

另一个选项是修改存储引擎怎么读取和写入数据。例如，使用innodb_flush_method=0_DIRECT，减轻IO压力，DirectIO并不缓存，因此操作系统并不能把MySQL视为增加文件缓存的原因。这个参数只对InnoDB有效。你也可以使用大页，不参与换入换出。这对MyISAM和InnoDB都有效。
另一个选择是使用MySQL的memlock配置项，可以把MySQL锁定在内存。这可以避免交换，但是也可能带来危险:如果没有足够的可锁定内存，MySQL在尝试分配更多内存时会崩溃。这也可能导致锁定的内存太多而没有足够的内存留给操作系统。很多技巧都是对于特定内核版本的，因此要小心，尤其是当升级的时候。在某些工作负载下，很难让操作系统的行为合情合理，并且仅有的资源可能让缓冲大小达不到最满意的值