一、两边执行计划的对比首先要看mysql那边的执行计划然后看达梦这边的执行计划那其实这里可以发现一个点mysql是有索引合并也就是index_merge这样的方式去优化的所以各个字段加了一个单索引也能有很好的性能。然而达梦数据库则没有这样的东西这也造成了一个问题是为啥明明是同样的索引同样的数据同样的表mysql运行时间只需要0.1秒而在达梦中却需要十多秒甚至更久。二、数据库参数调优的判断一般数据库相关参数的话达梦厂商来安装的时候会直接用软件扫描服务器后直接给一个最合适的配置我这次暂时不动。不过这里也给出排查的方法查询缓冲池命中率接近1则为最优。其中回收区 recycle命中率低是正常的它只是临时中转站SELECTNAME AS “缓冲池名称”,SUM(PAGE_SIZE) * SF_GET_PAGE_SIZE() / 1024 / 1024 AS “缓冲池大小(MB)”,SUM(RAT_HIT) / COUNT(*) AS “命中率”FROMv$bufferpoolGROUP BY NAME;一般normal区命中率在0.999以上都是非常优秀的说明几乎都是在内存中查询回去了那就不用管参数的问题。如果命中率很低的情况那就需要调整一些参数了比如以下几个参数仅作为参考和自己的服务器性能相关MEMORY_POOL 204800 #Memory Pool Size In MegabyteBUFFER 614400 #Initial System Buffer Size In MegabytesHJ_BUF_GLOBAL_SIZE 82000 #maximum hash buffer size for all hash join in MegabytesHJ_BUF_SIZE 4096 #maximum hash buffer size for single hash join in Megabytes三、索引优化那这个时候其实就可以认定为既然mysql自身的那些索引没有效果那么就只能利用达梦本身的索引了那其实最好的就是针对特别慢的查询做一个专门的复合索引。复合索引的创建原则呢就是过滤性好的字段放前面它会自动按照最左原则去查询只需要查询where后的字段都包含在索引中即可。比如针对这个查询主要看联表查的键以及where后面的部分创建两个复合索引CREATE OR REPLACE INDEX “FKGL0513”.“idx_kh_ydkh_composite” ON “FKGL0513”.“kh_ydkh”(“gddwbm” ASC,“cbqdbh” ASC,“yhbh” ASC,“yhztdm” ASC) STORAGE(ON “MAIN”, CLUSTERBTR) ;CREATE OR REPLACE INDEX “FKGL0513”.“idx_fk_yhda_composite” ON “FKGL0513”.“fk_yhda”(“dqbm” ASC,“ffms” ASC,“fkms” ASC,“dazt” ASC,“yhbh” ASC) STORAGE(ON “MAIN”, CLUSTERBTR) ;即可达成最优的查询效果四、索引明明修改了但是为啥没生效啊我真的好崩溃创建完索引后explain显示这样的效果可以发现它没有走刚刚建好的复合索引而是继续使用了系统给的主键即这个INDEX33589682然后回表查询得出结果为什么呢这时候需要用这个语句DBMS_STATS.GATHER_TABLE_STATS(‘用户名’,‘表名’,NULL,100,TRUE,‘FOR ALL COLUMNS SIZE AUTO’);提取一下表的统计信息。这种情况是它认为表数据量不大然后用了错误的执行计划即主键查询回表。当数据量大了之后就必须用复合索引才是最优。当刷新了这个数据后就可以重新判断执行计划了。ps此处需要重新改一下sql的格式以触发新的执行计划比如加个空格啊或者换个写法啊什么的然后就能发现它走了下面这个执行计划此时再去查询就能发现效率已经大大提升。五、不改sql的格式如何刷新执行计划呢毕竟我也不可能专门为了这个sql重新发布一个包吧select cache_item from v$cachepln where sqlstr like ‘%SQL语句的部分内容%’ 通过这个语句查询就可以得到关于执行计划的item信息可以看作是执行计划的唯一ID。然后将查出来的item带入这个语句执行call sp_clear_plan_cache(CACHE_ITEM);相当于清空了旧的执行计划这样再次查询的时候就会使用新的执行计划。此时再查发现耗时0.8秒对比之前的十多秒算是巨大优化了大功告成。