今天说说INNODB_BUFFER_POOL_SIZE和innodb_io_capacity。
Oracle和MySQL都是甲骨文的，我就借用甲骨文RWP团的一句话。数据库的绝大多数参数都采用默认就好了。我对此深表赞成，这里不要和我抬杠，我没说每一个。该团队说每一款产品出来都是要经过性能测试的，而在各种场景和环境下如果都要满足，就会有一个尽可能满足全面的配置。而且测试也是基于这个因素（通用）来做的。所以很多是不需要修改的。
我刚学习的时候，年少无知觉得改一个参数说明自己能力。后来才知道，其实没必要。我们需要知道这些是干什么的，但是不见得要调整。别指望改一个参数出现天翻地覆的改良，如果真的能这样，官方也不傻为什么不做成默认的？一定是默认的。说这些和今天有什么关系呢？
因为这个INNODB_BUFFER_POOL_SIZE必须改。因为默认就是只有128M。你日志组大小，你的线程多少，你的会话。都用默认的问题不大。依然不要抬杠，说淘宝和京东就没有用默认。你说的这种屈指可数的几个腾讯 拼多多 facebook 等等他们都用的还不是社区版，有的公司还是自己自研的数据库。而且他们的体量并发不是一般企业有的。这种毕竟少数。中国绝大多数公司没这个业务量。我见过也处理过一些朋友的公司的，注册用户百万，日活数万的就一个数据库就搞定了。根本不用sharding的技术。说实在的这种体量要是一个数据库搞不定，可以找找自身问题。也可以找我，我来处理，搞不定不收费。
我们还是说正事，为什么这个必须改，因为那些默认的都能支持你的业务。绝大多数业务。而这个是和内存打交道，官方不知道你机器内存多大。大于机器内存，启动有问题。所以就给个小的吧。这年头没有小于256M的机器了吧。所以你一定要改。我已经见过和听过不止一次，一些云服务商或者运维方就保持这个默认。这样用户机器就是有32G，给数据库的也就128M。就是欺负用户不懂技术。
Oracle12C有个特性，一键加载全库到内存。如果你的数据小于内存的话。为什么要这样，不就是内存快嘛？结果你用这个默认128，即使MySQL有这个功能你也加载不了。太小了。
innodb_io_capacity这个呢是和磁盘打交道。上面不知道你内存多大，这个不知道你硬盘多快。下图从网上找的，具体数值不重要，重要的是说明这个有差异。
我也见过不少的SSD上运行的是默认的值。基本没发挥出SSD写的能力。当然读和这个参数无关。就是硬盘全表扫，自然是有效果。毕竟大家都是写少读多。一个业务系统一天10w订单也就一秒1条。毫无压力。所以说中国一天1000w订单业务的有几个？单机足以。如果你配置是SSD，改改这个参数。妥妥没有问题。
SSD已经不是最快的了，你看看后面那种，硬件在不断进步。Nvme等是的关系型数据库上硬查也很快。exadata中一秒可以扫描350G，这种就是硬件带来的收益。
今天只是举例，这些不调你的硬件就没用起来。不像会话数，你调整到100万，但是其实你用到1000基本就宕机了。我没见过活动100多个，系统还挺好的。基本都已经卡着动不了或者响应很慢了。
