读写性能提升
查询成本评估的时候，加重表扫描的权重，降低索引的权重
感觉有点疯，不晓得为什么那么喜欢表扫描
现在天天为这事烦，虽然绑定执行计划可以临时解决，但哪有千日防贼的
最近从 mysql 迁移了，不出意外的出意外了，表扫描导致了严重的性能问题
迁移前做了慢查询的流量回放，没问题
由于各种原因限制，未做全量查询的回放
迁移之后，发现 TIKV 满负载，导致业务响应严重受影响，导致此现象的原因仅仅是因为平均2个/秒的一个查询
- 单独招抚这个查询，效率还可以，2秒左右
- 在mysql中，这个查询毫秒级，所以不在慢查询中
- 迁移后，在TiDB这边，这个慢查询出现了堆积，表扫描导致TiKV IO压力上升，快速堆积导致最终出问题
测试分析发现：
- 表扫描的 COST 1.7亿，INDEX-MERGE < 2k，居然走表扫描
- ru 显示，表扫描首次在300左右，后面为0.9，index-merge固定为 1.8（不知道是不是跟这个有关系)
现
适配性做的好点
总需要一个过程，阵痛是避免不了的
1、加大数据的压缩率
2、将PD的角色与tikv或db合并
3、分区表继续优化
4、物化视图
5、更丰富的API
6、dashboard集成更多诊断、维护操作的功能
看来大家还是满怀期待的
执行器，优化器
这样的话 和使用单机版的mysql有什么优势?
稳定性
始终满怀期待~
对,都可以
读写性能提升
支持存储过程
自定义函数
企业版已经支持存储过程，可以付费体验
读写性能的提升和存储过程
我希望优化的存储过程
企业版已经支持存储过程了，使用过程中遇到了什么问题需要优化？