1：目前是这样我要查询一个表数据量有20w。
2：主键是:ID
3：查询语句：SELECT ID,字段1，字段2，字段3，字段4，字段5…字段35 FROM 表。
3：主键索引是ID。
问题：（1）有时候这35个字段都有可能作为查询条件，怎么去优化？
（2）当没有查询条件的时候，这样子查也很耗时
请问大家这怎么优化？？
3 个赞
20W 这么少啊。
查询也要30s了
有时候这35个字段都有可能作为查询条件，怎么去优化
这就不应该用mysql
35个where条件，那还不如awk呢
单表查询？什么数据库？看看计划任务？还有看看是不是每个字段的数据量过多？硬盘问题？
单表，oracle，目前就给id加了个主键索引.
用的是oracle，myabtis动态去拼这个where条件
1、首先排除查全表这种离谱的事情 必须要有查询条件+分页
2、查询条件字段加索引 最好是重复比较少的
3、最好不要用子查询 如果用子查询 最好也是走索引或者主键 不然你临时表空间数据太大会爆掉的
1 个赞
目前的需求就是不分页，全量展示，就很头疼。而且这20w的数据Java里面还容易内存溢出。查询字段35个总不能35个都加索引吧
这么点数据都查询慢，堆硬件先
这个目前不可能
20w条数据全量展示？ 一个页面也放不下20w条吧 啥需求啊 20w条还好点 你这要是几千万条 内存数据库肯定会爆掉的 埋雷
用的虚拟列表展示的。数据量最大就20w了
35个你挑那种数据重复比较少 并且作为查询条件频率比较高的 结合实际需求去加一下 会好很多
什么场景20W全量展示?我想象不到…
去审核这些数据用户希望全都看到，不想分页。
20w数据应该怎么审核呢？不会要一条一条看吧
先优化一下子查询吧 子查询千万千万要走主键或者索引 我已经上生产爆掉一次了 还好是后台
这需求直接拒绝了吧 你现在是还能查 等数据量大了 不是你爆掉就是数据库爆掉
1 个赞
哎 我有一计
后端正常提供分页接口,前端做信息流
下拉的时候去分页
8 个赞