@tomorrowan 暂时没有前端的位置啦，谢谢。

太小了的确不用分。

HC 感觉很正常的交流啊 不知道的虚心问问或者 google 一下就好了。。。。。。
领域常用词汇跟什么 u1s1 这种不知道什么玩意儿的不是一回事吧。

第二个里面可以按照 「熟悉」 => 「掌握」 => 「了解」 从上到下 排版一下

感觉也不要写太多，另外最好注意一下相关技术的正确拼写 比如 mysql => MySQL
我觉得第二个方式不错，我的话我会用第二种。

死了

楼主好挑。。。

看了一半，觉得有点长就拉到最末，果然出现了预期的东西

语言是比 GFW 更高的一道防火墙。

6

很喜欢你们 APP 😆

买一些专栏可以在地铁上看。因为是碎片时间。

为啥才 1000w 就要分表了 - - 第二个分页的需求没看懂。如果一定要精确的 count 不大的情况下直接 count(*) 如果量大维护一个索引值 可以放 redis 也可以搞个表存。不需要精确的 可以使用执行计算的 rows。

我仔细看了一下楼主的描述感觉有可能发生这样的情况

我感觉 insert 那个可能是另外的问题。

推测
select * from tables_b where id=xxx for update 这个语句等锁超时了。
排除掉其他对这两个表的查询导致的情况
可能是 首先第一个事务执行了
begin select * from tables_b where id =xxx for update 锁住了对应行，
这个时候准备执行 update table_b set xxx=xxx where id =xx 但是 这个 xx 被另外的
begin select * from tables_b where id =xx 锁住了，就死锁了。
超过了超时时间，就报错了。

建议楼主如果是 5.7 打开 innodb_deadlock_detect=on 再观察一下。
如果还有类似问题要考虑一下这两个表是否还有别的加锁操作或者长事务在上面跑？

想问一下事务情况是怎样的。
上面说的
插入
查询 for update
update

这三个操作时一个 begin 事务 1，2，3 commit 的吗？

全日制需要搞一个。
同样的路我已经走过一次了，全日制本科很重要。