@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 是必须准确的，而且是需要考虑脏数据。

没有优化方法途径。count 就是慢。order by 也是慢

如果想就职，那么选择前端，研究 js 和 ts 也能达到 2w ，就业对学历不严，而且岗位 10 倍。

@qemu32

没有因为学历拒绝掉？-----------可能只是表达出来。

另外---------很多公司看的都不会看，简历直接过滤了。

而且--------未来工资上涨前途有限。。。。

联想用户告诉你，，，不要买联想。。。。。

只能存照片，啥都不能玩。

@fiypig

看同样时间点的 mysql 日志有什么，
你使用了 swoole 之类的长连吗？
搜索 mysql 参数设置超时，可能是超长时间没有交互，也可能是错误次数太多被断开。

@shakoon

drop 不写 binlog 吗？

需要监控的可以分为：

1,请求日志（耗时，频率）
2,错误日志（频率）
3,慢日志（数量，频率，top ）
4,资源状态（内存，cpu ，iops ，带宽，队列数量等等）

最重要的经验：

1,想办法写日志；
2,分析日志预警；

大学同学平时玩的飞起，课没上几节，期末考试前自己看书三天，还是能稳拿第一。

@pepsiwant

唯一精确要求的就是读音，一定要准确：有什么方法和诀窍？

周刊给个 rss 摘要订阅哈

@kalman03