起步

我着手一个需要高并发 update 的功能，进行压测时，发现了大量锁超时。于是所有矛头就指向我了，认为我做任务分发时重复分发了两个或两个以上相同的子任务。

这一假设基于现有的子任务 update 范围，已知更新语句走索引 c，则有：子任务 A 更新 c=[1,10] ；子任务 B 更新 c=[11,20] ... 子任务 N 更新 c=[n-9, n]。所以同事认为，只有可能会出现相同的 A 任务（B、C ... N 都行），才可能引发锁超时。

假设同事是正确的，那就意味着 update 只锁主符合条件的记录。但果真如此吗？

起步

同事告诉我 update 时，如果没走索引，会锁全表；如果走了索引，只锁住符合条件的行记录。

所以果真如此吗？好像不是欸！

起步

借助 Docker 容器部署 MySQL 主从数据库。以下内容涉及路径、端口等可更换内容会额外加以说明。

如果你还没用过 Docker，不妨先看看 Centos7 上安装 MySQL。

起步

在 Centos7 上安装 mysql 是一件比较麻烦的事儿，要么将源码拉下来自己编译，要么忍受乌龟爬的外网。只要操作简单，方案可行，乌龟爬就乌龟爬吧——如果你抱着这样的想法，不妨转至这篇文章 CentOS7安装MySQL（完整版）。

本文是想寻找一个折中点。既保证 mysql 正常使用，又不必被网速闹心。我仔细思索过，觉得借助 docker 容器是一优解。

019.8.3

起步

最近公司接到一个项目，任务是根据需求制表。完整过程是：用 SQL 汇总数据，再写进 Execel 文件中。SQL 这门课倒是大学里学过，过久不用，不记得许多，顶多 SELECT 几下。总之是勉强应付。

这周五接到一个需求，差点应付不过去，卡在联表操作上了。午觉再不敢睡，总结 MySQL 查询时的多表联合。临阵磨枪管用，当测试发来 “OK” 的时候我这样想。

笔记至此，遗忘再寻。