你建个字段 vaccination_unit_id 和字段creation_time 的联合索引不就行了。。。。
用过的国产分布式数据库中,ob和tidb都不错,ob有对oracle语法的支持是一大强项,tidb对应的监控组件要更加的全面。
有些pg套壳魔改的,真还不如用pg呢,在人家的基础上改一堆垃圾出来,然后号称什么对oracle兼容95%,那不就是pg的oracle插件吗?有些国产数据库真的是脸都不要,就靠一个ppt在那硬吹,签合同前,dblink,存储过程什么的这些功能都有,签完了这个不建议用,这个有问题,我都无语了。
谁说的,hint只是提示,并不是强制的,如果cost差异过大,cbo优化器有可能不听你的hint的
这个端口不是固定的吧,你重启下应该就换了,主要他不是只绑定到127.0.0.1上吗?管他干啥
是的,看你默认的执行计划确实比hint消耗还要少啊
不是读热点实在无法处理的,没啥必要开follower read,开了效果也不是很大
在这里,我与许多优秀的社区成员分享知识、解决问题,同时也从他们身上汲取了源源不断的动力。我也希望能继续为社区贡献我的力量,让我们一起不断创造更多的价值,让 TiDB 社区变得更加繁荣、更加开放,成为更多开发者的家园。
连续也没用,因为你的region会分裂的,分裂都是从中间分,_tidb_rowid就算开始连续,后面也不连续了
目前该 Hint 生效的条件较为苛刻,包括:
如果查询有除了全表扫以外的单索引扫描方式可以选择,优化器不会选择 index merge;
理论上你的tikv足够多,表多大都可以的。。。因为数据是分布到所有tikv上的
表大的话建议手动收集,可以WITH FLOAT_NUM SAMPLERATE分析小样本的数据,如果是全库有很多大表,又不愿意耗费太多的统计信息收集造成的消耗的话,可以将 tidb_enable_fast_analyze 设置为 1 来打开快速分析功能,不过不建议这样做,可以将tidb_auto_analyze_ratio自动阈值调大,然后部署手动任务对大表进行小样本分析
当然也可以升级版本
首先,tikv不支持2个不同的目录
其次,tikv不支持修改目录