合理个锤子，领导无能累死士兵。不让用的本质原因是领导自己能力太菜，担心员工能力也菜，用不好，反而拖累数据库。就像现在很多城市禁摩，并不是摩托车污染环境，本质就是管不好，懒政。任何技术都要使用在合适的场景，合理的使用。

阿里的规范是禁止使用存储过程，不是禁止使用 join 。

禁止使用 join，是否能够提高效率，减轻数据库的压力？
答案基本是否定的：
1. 试问各位那个有信心能够写出数据库查询引擎，写出的代码效率比 SQL 引擎效率更高？
2. 不使用 join 和业务实现没有关系，业务实现还不是要从数据库拉取数据，难道这个步骤不增加数据库压力？
3. 完全禁止 join，不如使用 NoSQL 数据库。关系性数据库合理使用就包括使用 join 。
4. 如果感觉业务开发写不好 SQL, 不如增加 DBA HC，做 SQL 审计，效率和质量都比不适用 join 好，并且能节省开发时间。

1. 为什么「先用子查询查出数据，再用 order by 排序子查询的数据」的方法行不通?
2. 这个查询除了对 columnA 建索引外，有没有其他更好的优化方法?

答：
1. 数据库做了逻辑优化，所以查询路径是一致的，当然你可以修改数据库统计信息，来欺骗数据库。如果数据库统计信息没有错误的话，数据库给你的执行计划就是相对最佳的执行计划。

2.
A. 如果建索引要建的是 columnA 和 timestamp 的联合索引，而不是单列索引；
B.更好的优化方法：
1) 改业务，不需要排序；
2 ）换存储（ RAID 、SSD 、傲腾等），增大内存；
3 ）架构层面增加缓存系统，REDIS 、memcache 等；
4 ）数据库缓存结果，或者使用物化视图；
5 ）优化 SQL，增加联合索引；

供参考😀

自由学习一门语言，
学习一门手艺，
欣赏一部电影，
去遥远的地方旅行。


奔涌吧，后浪🤪

[user1@node1 ~]$ whoami
user1
[user1@node1 ~]$ id
uid=1001(user1) gid=1001(user1) groups=1001(user1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[user1@node1 ~]$ sudo cat /etc/sudoers | grep -v "^#" | grep user
user1 ALL=(ALL) NOPASSWD: ALL
user2 ALL=(ALL) NOPASSWD: ALL
[user1@node1 ~]$ ls /root/
ls: cannot open directory /root/: Permission denied
[user1@node1 ~]$ sudo su user2 -c "sudo ls /root"
anaconda-ks.cfg anaconda-ks.cfg_bak original-ks.cfg

@wushigejiajia01 不是后浪，只是够浪🤦‍♂️