【 使用环境 】生产环境
【 OB or 其他组件 】ob
【 使用版本 】4.0
【问题描述】
gjfq是分区表，和gj表数据基本一致的
执行查询，发现时间并无差别。
想问下，这个是什么原因那
1 个赞
全表查的话，数据量大了，分区表性能可能反而会降低。
分区表解决的并不是查询性能变好的问题啊。
数据量很大，带上分区键的分区表查询性能一定会变好，但是不带分区键，那很可能变慢。因为从单机单表变成了多机分布式的分区表了，多了网络交互。
2 个赞
建议对表进行分区是为了把数据分块，尽量让 SQL 能裁剪分区，查询更小范围的数据，不是说分区了能把不分区裁剪的 SQL 性能搞好，要是这样的话，那岂不是能一劳永逸，遇到大表导致 SQL 性能不行就分区。
1 个赞
执行的查询的时候加上分区名p2022sp0,这样进行查询吗？
1 个赞
两种方式：
一种是带上分区名
另一种带上分区键，比如你A字段做的分区键，那sql都带上分区键，A='xxxx’这种，分区裁剪，将不需要的分区不执行查询，直接定位具体分区，然后提高性能
1 个赞
老师，这样的话，和mysql分区有什么区别那？
我们现在没理解分区了和分布式的关系，和老师沟通，说是分区了可以实现分布式运算。
1 个赞
就是兼容了mysql的分区啊，和mysql一样，只是ob自己可以实现不同分区在不同机器上，这样物理资源上就可以多级并行啊，物理资源就不会是瓶颈了。不过这个取决于每个zone的机器数量和unit num
这个配置看起来还好
这样的配置，物理资源应该不算瓶颈了吧。
现在我们的问题是索引都没生效，指定id进行update都很慢。
CREATE INDEX IDX_eventTime ON gjfq(eventTime) LOCAL;
这样有什么问题吗？
DDL查看索引是都在的
您把您的 两个表的 DDL 语句发出来， 再把 查询语句发出来。 要是select * .估计提升不大
DDL不太方便，唯一的区别就是索引和分区的配置。字段都是一致的，gjfp就是gj的分区表版本
方便的话，可以钉钉发给您
看下查询计划吧：explain select
update 时 带上id + 分区键
另外，如果你业务已经上线，没办法改SQL，加个global 索引（id）,然后使用outline绑定一下索引
两个表的执行计划看起来都走了全表扫描，麻烦贴一下你的查询语句
执行sql不确定在哪个分区啊，这个怎么处理那？
SELECT * FROM gj;
SELECT * FROM gjfp;
如果创建了索引，应该要带上索引键=xxx这样去查吧