多表关联查询重要的就两条：

1, 先查结果集少的表，再查大的；（通常先查索引稀疏且分布均匀的）
2 , 索引必须用上，且尽量用主键关联；


优化也是三板斧：

1,show processlist
2,explain
3,slow query

你看的不是我这个吧： https://c4ys.com/archives/2349

你这个必须临时表，而且查询集是 n*m 而不是 n+m.

你这个需求有点奇怪，没有 where ，所以没法缩小结果集，只能都跑全表。

大家都开始不用的时候，就开始重视了。

@dengjscn

长沙 40w 还得看项目经验和学历。想完全不加班比较难。
可以招聘岗位搜索下或找下猎头试试，还是有的。

没有人格式化，装 windows

@CHUB

过了过了，哈哈。。。

虽然你说的很有道理。

不过刷刷题，看看视频是打基础。

所以，楼主想表达的是：侄女基础可以，大家有没有内推的？或者其他途径。


@2bad4u

现在已经不是当年我们那时候了，开源项目提交几个问题和修复，就能收到大厂面试通知。

而且每年一千万大学生，三百万研究生，这里面计科生应该是占比很大的吧，地主家粮也不多啊，

双非 8k 刚毕业可以试着干了，刚开始几年都是慢慢涨的，干两年后做得好转管理应该可以双倍？不过楼主经常逛 v 站，那时候觉得双倍估计还少了。

star 多：面试题，awesome ，换皮。

@djoiwhud

超过 15 的肯定不止 10%。。。。
至少 20%以上。。。我身边差不多 40%以上吧。

中软不卷，工资 1.5+，招人也比较多。


当然来长沙，你想跳就难了。

@dengjscn

40K 有难度，名校毕业五年管理岗经验有可能。

@djoiwhud

普通 java 开发是差不多，所以需要简历优化服务。。。哈哈哈。
收费一次只要一千。。。
一个月回本。

@itechnology
@undefine2020

1.5 以上的岗位很多吧，当然还要看人啊。
我五年前从深圳过来，那时候基本打 5 折到 8 折吧。我是打了 6 折的。

不过有小孩，想安家还是长沙吧，深圳房子太贵。


想知道工资，去各平台搜索下，不就知道了吗？大公司取最低的，差不多等于平均中等偏上。

@elfive

1,可以买二手，哈哈，便宜量又足；
2,麓谷这里还好，修完了，公司也多；
3,不要找加班的，麓谷这里边上开车小电驴，上班不要超过半小时；
4,工资找 1.5 到 2.5 还算好找，超过就看你能力和机会了，得等。


既然都选择来长沙了，就是躺平模式，买房育娃，工作生活平衡，不要选加班公司，大家共勉。

是在缺钱就选择万兴吧，据说前端也有 2.x 起，九点不算下班。

上市公司和子公司也有一堆，得慢慢找，不要急。

pg 100 万数据，select count(*)和 select count(id)也都是一样的索引，一样的 200ms ，刚试过的。

所以：

不要相信关系性数据库 count 能快，是要实际排序计算的。

不要相信数据库工程师很菜，不会自动分析走哪个索引，明明有更优化的索引不走，走个慢的。

@wangxin3

这个特性好像是 20 年前的 myisam 引擎的，不是 innodb 引擎的。

@wangxin3

对不起，我用的 mysql8.17 没有这个功能。
explain
两个走的是一样的索引。
同时走了一个 tinyint 的索引。
你可以在线上试一下看。

@cy1027


就是 navicat 自动给你加了 limit...
然后他的统计是来自 infomation 表的大概统计，如果你仔细看前面有一个约等于符号，我没有记错的话。

你直接用命令行 select * 看看，一片跑一边看 show full processlist ，几十万数据 send data 状态都要几秒吧。

数据库的耗时有几个阶段：

查询解析：分析关系，走哪个索引？
取数据：内存（走了索引）或磁盘（没走索引）？
预处理结果：排序或格式化等，走了内存或者临时表？
发送数据：发数据到客户端，结果集大肯定慢了

结合慢查询，processlist 和 explain 可以发现并解决问题，如果是我前面的问题，基本无解。

如前面所说，我刚才试了下，在我的阿里云小 rds （ 1 核）上，900 多万数据无论是 select * 还是 id ，都需要一分多钟，两者走的是同样的索引，所以实际项目我都是加了条件限制的，默认只查当个月数据，用户加日期建立了组合索引，不让用户直接翻页到最后一页。

一定要精准电量显示，
底盘重一点，没有那么漂，
大一点买菜方便，解锁速度能上来，小一点不能解锁，因为太漂了。

关系数据库几个很多无法解决的问题：

1,count 慢
2,order by xxx limit 1000000,10 （取最后页的慢）
3,like “%xxx”慢
4,没有合理建立索引慢
5,自动更新物理试图
6,。。。

以上等等限制才会有 es,mongo,hbase,redis,InfluxDB,GDB 等等的机会。以上导致关系数据库没有走主键索引的话也就千万级别数据量比较合适吧。如果都是走主键那随便放。

navicat 的统计自动走了统计表，不是准确的。

count 是必须准确的，而且是需要考虑脏数据。