坑人的innodb_thread_concurrencyMYSQL的优化器是硬解析, 应用每次发往MYSQL的SQL是文本格式,需要编译,虽然时间不多,也就几百毫秒的事情,可架不住SQL的请求并发量啊!
 

为此数据库走了两条路线, 一条是ORACLE的缓存路线, 另外一条就是MYSQL的快速路线.

ORACLE是尽可能的深度编译,找出最快的执行计划(编译后的二进制代码),然后把它缓存在内存里,下一次就避免再编译,直接从内存里拿出来执行就是了.

MYSQL 路线是浅度编译,快速出成果! 所以大家都会觉得MYSQL优化器比较弱智.对存储过程支持很鸡肋!

其实MYSQL面对互联网购买的业务,简单,比较简单.只是并发量太大了,所以简单优化器也体现其价值.

我们可以通过编程,拦截手段在语法分析完后进行拦截,

或者SQL语句与参数分离后形成DIGEST. 我们拿着个SQL的DIGEST,

也就是ORACLE的SQL_ID. 然后对比我们内存缓存的SQL.没有得话扔回MYSQL只身的优化器去优化,然后去执行.

如果有的话,我们就从内存里找到SQL执行计划,再丢给执行器去执行.

然后我们采用命令方式把SQL送给深度优化器,产生多个优化结果,返回给DBA选择.DBA选择其中一条或多条. 存入内存里.

如果数据库关闭的时候,我们把内存里的编译结果,共享池持久化到磁盘上.

这点ORACLE没有! MYSQL有把数据缓存池持久的功能.

比如说我们用 ALTER SQL PARSE SELECT * FROM TABLE WHERE A=?

或者具体值. 然后返回多个执行计划 ID ;

使用命令 ALTER SQL SAVE PRANT ID IN (323423,324235234);

就把当前的SQL深度优化器产生多个执行计划保存在内存里.

最后我们提供个内存视图 查看目前缓存了哪些SQL语句? 每个SQL语句有多少个执行计划? 每个执行计划参数范围; 每个执行计划命中次数,最后一次命中时间.
 

最后我们还要提供命令对某个内存里的SQL进行清理

ALTER SQL DELETE BY DIGEST;

ALTER SQL DELETE PRANT BY ID;

最后是以MYSQL 插件形式开发和安装XXX.SO

为什么要这样子呢? 主要解决MYSQL弱智的优化器, 添加深度优化器有利用解决MYSQL对商业SQL的支持.目前这个市场由ORACLE坐头把交椅,PG为老二!

商业SQL 比如说计算工资等复杂数量的计算. 这些计算基本是离线状态计算,并不影响MYSQL互联网高并发SQL请求. 即使上生产环境,也是上的从库.

开发出来还是有点前景 为MYSQL社区做下贡献, 成为真正的MYSQL大佬级人物,是全球性质! 比ACE 老师们 荣耀高多了!

坑人的innodb_thread_concurrency

MYSQL分区NOW()不支持

MYSQL ROOT密码忘了怎么办?