关于#java#的问题：MYSQL查询一千条数据花费3.5s 并且随着数据量花费时间越高

MYSQL查询一千条数据花费3.5s 并且随之数据量增加到5000花费时间更夸张的达到15s左右

tbl_student 建了索引但不知道为什么没有走索引

1、检查left join的那些字段是否都设置了索引
2、使用explain查看执行计划，看一下哪些字段没有走索引。
3、if 下面那个子查询字段是否走了索引？思考一下是否一定要使用子查询？
4、查询的字段是否全部需要，去除不需要的字段，最好只查询可以走索引的字段，从而避免回表查询。

总结：连表查询尽量通过索引去连接，尽量避免子查询，没有索引的字段赶紧建索引，快通过explain分析执行计划。

那是因为你这left join就很夸张
10多个表关联之外还有嵌套查询，不慢才怪
把所有参与查询的字段全部做索引

leftjoin就不说了 最后那个字段school 还是关联嵌套查询也是够够的了，数据量越大花费时间会更长，建索引也只能初期数据量比较少可以有点效果，真到业务数据量起来了 估计还是得重新设计表结构

如果使用join 建议3个表左右，
想你这种情况，不仅效率低，到时候排查错误也是非常让人头疼的一个事
再考虑一下你的表关系，重新写SQL语句，或者学学SQL优化的知识

join最多连接3个表，从来没见过说这么多表。 数据看是否能合并不，能合并就合并，还有建立索引，数据分开查询进行组合 ，正常情况下1000条数据也就0.0几秒加载完成

减少join，把join的逻辑挪到应用层，mysql的join 性能很低

1、关联的数据表过多，建议考虑优化数据库结构的设计、或者增加临时表来处理
2、确保 left join 关联字段有索引
3、里面还有子查询可以考虑优化

看到这么多left join ，里面还有个子查询，这时间一点都不意外

1.需要分析索引以及执行计划，分析是否存在全表扫描以及不合理索引。
2.从SQL语句优化层面来说，再不改变当前业务的情况下，可以考虑将那个复杂的子查询变成结果集后进行关联，也就是在子查询数据生成的时候作为一条结果写入表中，然后去关联查询。
3.如果可以引入新技术的话，可以考虑使用mysql的bin log进行cdc数据复制，推荐Alibaba开源组件Canal，然后将需要聚合的数据汇集成一个结果集写入elasticsearch以提高性能。
总体来说mysql的性能优化是一个全方位较为复杂的体系，就目前提供的资料来看，还是需要考虑一下。

join的表太多了，还有嵌套子查询，可以考虑做宽表，将一部分字段冗余到主表，每次查询数据量小可以考虑在内容里组装数据

你这是联表呢？有点过了啊。
一劳永逸：重做表结构，你这个太不合理了。
临时办法，也就是你要的快速解决：建立视图。

sql写法有问题，真不知道为啥这样写法。首先left join和嵌套查询特别消耗时间，而且一下关联这么多张表。建议关联表之间关联字段肯定存在的那些关联表改为inner join，其次将sql拷贝出来，然后再数据库客户端使用explain + sql语句执行一下，然后优化下sql，同时建立一些合适的索引字段

思路：目前看SQL关联过多，且规范较差。可以通过EXPLAIN或者show profile分析SQL并进行优化。
建议不要关联这么多表进行查询，可以看下阿里开发规范，是提倡简单查询的，非必要的关联尽量不要做。

你这join太多了，不符合业务逻辑，有学会优化sql

我去，你咋不再多连点表，连表查最好不要超过三张表，你这样查，查询条件都加了索引都没啥效果

join的表太多了 ，并且没有加条件， 这样会有一张表不会走索引 ，你可以看一下执行任务EXPLAIN

1.首先评估一下真的有必要一次性关联这么多表进行查询吗？
2.检查索引建立的是否合理

关键太多了，还外联查询，肯定慢

新建视图，减少左连接