tidb在没有分布式ddl执行框架以前（7.5版本以下），tidb只有ddl owner才会执行ddl。也就是说，只会有一个tidb server在执行ddl，这就是加索引慢的根源。
因此从机制上我是不太相信能造成3个tidb cpu都高。感觉是有别的问题。
1 个赞
是的都高，tidb就是这样
tidb因为一个sql就会导致别的sql阻塞，导致都高
你这理解不对吧，tidb是无状态的，sql只会在一个tidb节点运行，不会影响其他tidb节点。
我理解的是不对，但是现象是这样的，而且很频繁
我们报表本身就有一定复杂性，这个问题基本上三天两头就会出现
当然了使我们本身sql有问题，但是问题现象就是都飙升
是我们sql问题
可以在dashboard中topsql和sql语句分析中看下哪些sql调用频率高消耗资源大。
大的我们能改的都改了
这个问题就下一子难住了，想加个索引提升下性能
现在根本不敢动，而且我们机器平常就30% 40%
资产都说我们利用率太低
有复杂报表建议上tiflash，在kv中查这种资源消耗太大
您也知道，有的sql加tiflash不一定有加索引快，我们也要比较
我就说个实话，别人问我tiflash能提升多少性能，我怎么回答，其实我也加了几百个，情况差别也很大，我自己心里也没数的
正常情况下带 group by 的这种聚合查询，mpp模式下，提升2-10倍很轻松。
如果没用mpp，生成的执行计划只是从tiflash 做scan。那可能是负优化。不如正确的添加索引带来的提升。
其实对于我来讲也是使用吧，不是开发，本身上很多东西也不了解，你说为什么都高，我也是猜测，具体原因要怎么看我也不是很清楚
有空多看看教学视频，学起来很快的
正常DDL Owner只有一个节点，三个节点都高应该不是DDL直接引起的