@zts1993 黄龙时代 /黄龙国际 /德力西还是满满当当的，z 空间那边坐不下。

@locktionc 这是在西湖区，网易杭研在滨江……

首先，单表 5000 万并不需要分表，极端一点的情况就是考虑下表分区。
其次，不要在 5.7 版本以前的 MySQL 中执行 count，无解，带条件尤甚。
5.7 的 InnoDB 提供了 records 接口统计，https://dev.mysql.com/worklog/task/?id=6742
以及官方提及的“ The next worklog, WL#6605, is intended to return the COUNT(*) through this handler::records() interface almost immediately in all conditions just by keeping track if the base committed count along with transaction deltas ”

@yilin12 因为这地方在景区，加上黄龙时代+黄龙国际+德力西工作的阿里众，再算上浙大玉泉校区供不应求的青椒宿舍的求是村也在旁边…… seriously，古荡新村和这个差不多装修的也接近 5k，山水人家的问题是太多群租以及一些设计极其奇葩的超大户型，嘉绿则能看到各种常年出租乱糟糟。
一室的我也看过，世纪新城 /城市芯宇这种，或者稍远一点在黄龙和山，基本都在 4k 朝上。

1.不会。
2.评价在跨业务部门的情况下看不到，hr 能不能看不确定。所以不用太在意这点，尤其是两个岗位 jd 描述差别巨大的时候。
3. p6 没什么意思，7 其实也就那么回事，6+也就 400 多一点。
4.杭州还有网易杭研 /华为杭研 /酷家乐这些，不是非得在这边吊死。

我屮艸芔茻给跪了……先考虑建视图，再用游标逐条尽量把分析的东西放业务逻辑，如果不行就用存储过程重写这段逻辑，触发器的话我并不推荐，原因是不知道这张业务表的关联性。

@KamiWan 我就不自取其辱了，再说有个其他部门的流程在推进。

@fanqianger “专家”，其实这是 p7 起步的职位，大部分应该都要给 p8，这俩个职位对标的产品线看起来是 GPDB 和 Spanner。
第二个还好点，看起来是想招一个不管人只管事的技术专家，而且本身强调的重点是“强一致性”，这个要求对分布式事务和数据恢复的理解非常高，没刷过论文只做工程的怕是到时候要被人追着怼；第一个这是真的难，从 SQL 优化一直横跨到 ML 和硬件优化，这是奔着某些团队的总监和业内资深去的。

有 patch 经常看 CIDR VLDB，还对 spanner 有深刻了解，这样的要求给 p6 p7 难道有人愿意去……

MariaDB 和 Percona 有讲 pagination 的，基本思路是在前端过滤掉不相关的查询进而摆脱 offset，使用自增主键来计算当前 pagination 所需的查询列表。
https://mariadb.com/kb/en/library/pagination-optimization/
https://www.percona.com/files/presentations/ppc2009/PPC2009_mysql_pagination.pdf

keyspace notification，这个只和订阅频道有关系，和连接节点没关系。但这种方式目前不保证所有的通知都一定能被接收。

不考虑转行的话，人力 /行政 /猎头 /测试 /产品 /交付 /售后，选择还是挺多——实际上我还是挺推荐程序媛不想写代码了转猎头或者做 recruiter，原因很简单，有一定技术 /人脉积累，对什么样的 candidate 符合什么样的 jd 条件是比较容易理解和学习的，以及什么水平大概适合什么级别的岗位也有预估。不要小看这个优势，人家一天联系十个只有两三个，你一天联系五个有四个符合条件能出面试报告，这可是成倍的效率提升。

@kenduffy 我猜你想说的是是不是要开启自动提交事务，亦即在语句中是否要加入 autocommit = 0。
mysql 默认是开启自动提交事务的，在非显式使用 start transaction 的情况下，每条语句都会作为一个事务自动进行提交。对于你所说的 bulk insert，是的，推荐你写 on duplicate key update，而不写 auto commit = 0，除非是你自己想要在后面还做其他事情，然后手动加入 commit 语句。

顺便再就楼上添一句，也是针对 @justicelove 所疑惑的，实际上 insert 出现 duplicate key 的情况下，一般 bulk-insert 推荐写 on duplicate key update，这种情况是有可能出现不可重复读的，取决于语句先后顺序和执行时间点。

还有一点就是关于 auto increment，在较早版本(5.5 或更早？存疑)的 mysql 所自带的 innodb 版本，bulk insert 可能会出现插入顺序 123 实际写入顺序 213 的情况。

@1010011010 To be exactly，autocommit 是分级别的，全局 /session/语句，以及是否允许脏读 /可重复读 /幻读这些现象也是根据 innodb 所支持的隔离级别而有不同支持。
简单总结一下，就是 innodb 目前支持四种级别的隔离级别( https://dev.mysql.com/doc/refman/5.7/en/set-transaction.html)，对应现象分别是：
隔离等级 脏读 不可重复读 幻读
未提交读 可能 可能 可能
已提交读 不可能 可能 可能
可重复读 不可能 不可能 可能
可串行化读 不可能 不可能 不可能

回到楼主的问题，哪种级别的 autocommit 都不影响，只有事务隔离级别对语句有影响，而 innodb 默认的事务隔离级别是可重复读，可能会出现幻读现象，亦即 @justicelove 所说的情况，存在该 bulk-insert 语句执行完后因为其他事务干扰导致的结果与预期不符情形，但不会出现脏读亦即语句未成功执行而出现部分数据被写入并被其他事务读取的情况(换句话说，如果其中有任何一个值插入失败，整条语句都会被回滚，但取决于 innodb 的磁盘刷新策略和时间点可能会有部分数据仍在内存或者已经落盘亟待清理的情况，但不会允许其他事务读取这些脏数据)。

@cstj0505 什么，你用 pg 做 olap 不用列存…… copyin 这是客户端的水果糖而已，字节流而已，实际上就是命令行的 copy，mysql 对应的是 csv load data，你先查查这二者的对比再来说……
你抬 pg 我不知道啥基本想法，德哥给 pg 打过多少年广告了，从来没有什么拿 copyin 来作为切入点的。顺便给德哥打个广告，https://github.com/digoal/ 算是国内 pg 业界内资深大佬吧。

说都说不到点子上，一般吹 pg 比 mysql 好都是要吹流复制、并行读写、pgxz/gpdb 的事务管理，还有就是更完整的软件生态比如 cuda/ml 接口库，比如多应用类型支持，比如扩展数据源接口等等等等，有时候还会吹一吹查询优化器的遗传算法+动态规划。你这个例子里 pg 支持的列存引擎是速度差异的最重要因素，估计你光看结果都不知道为啥……
只做应用和运维的话，最好不要贬低一个抬高另一个。

不要立个假靶子。现在流行的是并行，不是异步。