以一次经历谈MySQL内存参数设置

  前一段时间被MySQL折腾得够呛，当时都没地儿说理，虽然过去那么久，有时想起来仍然觉得有点恼火，当时要给数据分析组新建从库跑分析业务，先前数据库复制架构为一主一从，线上业务读定分离，数据分析跑的基本上是全表查询，会对线上业务查询SQL执行效率有影响，给新建从库单独跑数据分析合情合理，想着很简单的一件事，谁知会是一段让人难堪的经历。我们在习惯地工作环境下，好多事情顺风顺水，然而当环境稍微变更，有异常出现，各种巧合的因素凑合在一块儿时，对自己既有认识的怀疑乃至颠覆就这样开始了。当时使用的DBMS是MySQL的一个重要分支——Percona Server,这个分支总的来讲对MySQL作了很多优化，算是挺不错的，行业内好多公司都在用。先不扯这些了，接着讲我的经历：
   当时我顺利将新分配的虚拟机上将数据库软件（percoan server 5.6.12)装上后,将从库数据库服务启动并change master后，觉得一切OK，坐等试运行一段时间，期间查看错误日志显示有无异常，监视复制延迟是否在可接受范围内，等一切都妥妥的，就可以交付使用了。呵呵，正常情况下是这样的，可正如前面说的，环境稍微变后......考验才正式开始。交付使用两天后，我发现了异常，数据库实例内存使用完全不受相关参数限制，难道我对MySQL内存主要参数理解得不够深刻，怎么可能，咱好歹玩了两三年的数据库，从oracle到MySQL,再到非关系数据库，虽然技术算不上一流，但自认对数据库技术进入过系统的学习，也有所积累，早就入门了。但当时看着内存量使用不断增长，过一段时间后进程有被KILL掉的危险，想到这些，很难让我再坚信自己已有的认识而不去怀疑，任凭内存疯长，不去找答案，就有点死脑筋了。
   内存相关参数设置得不合理，线上环境没有暴露出来？我们线上MySQL数据库主要使用MyISAM和Innodb存储引擎，以InnoDB为主，由于MySQL使用插件存储引擎，内存使用方式不一样，因些需要针对存储引擎分配内存的使用。
    Myisam:
     key_buffer_size：指定key_buffer的大小，用来缓存Myisam表索引数据，属于全局设置，供所有线程使用，   
     read_buffer_size ：对Myisam表进行顺序扫描时使用，属于session级，扫描每一个表时都会分配
     read_rnd_buffer_size：当按照某个索引对Myisam表进行随机读取排序时使用，属于session级
     myisam_sort_buffer_size = 64：用来分配给Myisam表重建索引或者修复时进行索引排序，属于session级
    
    InnoDB:
    innodb_buffer_pool_size：buffer pool用来缓存innodb 数据页、索引页、undo页、插入缓存页、自适应哈希索引、数据字典信息等，使用保证其命中率，其大小属于全局配置，内                                                 存使用的大部分
    redo_log_buffer：重做日志缓冲，设置大了也没多大用
    innodb_additional_mem_pool_size：额外内存，innodb存储引擎使用内存堆的方式对内存进行管理，对内存堆本身数据结构的缓存需要使用额外内存，缓存的是一些数据结构， 如果不够，会从buffer_pool申请，例如lru列表信息

  其他：
    join_buffer_size=256K：join_buffer用于执行全索引扫描，索引范围扫描及没有使用索引或者全表扫描的join操作，属于session级
    sort_buffer_size = 1M：为排序操作分配的buffer
    table_open_cache：所有线程open table数
   table_definition_cache：缓存表定义信息(.frm文件），全局配置，不像一般的table cache用到文件描述符，使用应设置大一些，加快open table的效率。
   query_cache：查询缓存，线上我们一般禁用
   thread_cache_size：缓存被重用的线程数。
   binlog_cache：缓存binlog，session级配置
   tmp_table_size：与max_heap_table_size比较，取其大，当进行group by聚合操作或者子查询时所创建的临时表占用内存的大小，属于session级。

MySQL内存配置就这些，内存使用量可以通过以下公式进行评估：
    global 内存+connection数*session级内存使用量

外加Mysql实例额外使用的内存，按理讲15G内存使用量到顶了，谁知实例进程占用内存量达25G，眼看要被系统kill掉(oom)，后来使用mmap查看内存映射，很是明显innodb_buffer_pool按照instance数被划分5个共享内存段，除此之外，还有一段特别大的内存段，约10G，不理解（很遗憾当时没有截图,），只是敢断定是异常现象，stackoverflow也找不到答案，只有一个案例，但无人回复。后来实在没辙，对MySQL软件进行了升级，升级到oracle 官方版本，结果迎来了转机，运行一段时间后，同样配置，内存使用量在自己评估的范围内，看来percona server还是有坑的，线上使用SSD时这个坑没有被踩到，使用raid 5时给踩到了，可能percona server针对ssd做了相应优化却不适用于raid 5吧。