岗位长期有效~~~~

在看机会的可以发送简历到
tianzhen.wtz@alibaba-inc.com ，或者加我微信 173 6453 6392

阿里的 DTS，很棒的迁移工具

先读经典的 thinking in java

查阅 distinct 函数

分两条 SQL 去查询，在逻辑上是不严谨的。先不说隐式转换的问题，当前的业务逻辑需要修改为一条 sql 在数据上才是一致的严谨的：select * from A where name = 'str' or id = 'str'

然后我们再说隐式转换在 mysql 的设计：When an operator is used with operands of different types, type conversion occurs to make the operands compatible.

DMS 啊 https://dms.aliyun.com/ ，开发环境线上环境能够映射起来，还可以自动对比，很好用

换 ssd 就够了，“慢”基本上都是卡在硬盘上。

一般客户端要定时收到消息有两种方式：
客户端定时主动拉取服务端数据，也就是客户端 sleep，然后拉取接口信息，这种的实时度要看定时的频率。
客户端服务端保持一个长连接，由客户端发起数据推送的请求，达到实时推送的效果。

建议使用“个推”、“极光推送”等这种推送服务。

没人用阿里云的 DMS 么。。。

使用整行匹配来更新资源库的数据。
update t1 set id=x1 , name=x2, xx=x3 where id=xx and name=xx and xx=xx....

如果资源库没有修改，那么 where 是能够和源库前镜像匹配的，这时候可以匹配上数据并执行更新。
如果资源库有修改，那么 where 后的条件是匹配不上资源库上的记录的，也就更新不到这个数据。
这样就能完成你的业务了。

纯翻页性能没有太好的方案。1l 的方案是记录下索引的值，比如使用 pk 将 sql 转化到索引上来查询提高效率，这样需要业务来改造代码完成。千万级别的数据，能翻它的人有多少，绝大多数都是限定条件下的查询，这样的数据量很可控的，如 2l 所说。

50G 的表，剩余空间为 40G。不管什么方式的碎片整理，基本流程是拷贝数据到新的存储上，随后释放原存储。如果碎片率大于 25%，[可能]会成功。为了保证 100%成功，建议清理其他表空间的历史数据来释放一些空间给这张单表做碎片整理。

explain 是最实在的，其他的工具基本也都是基于执行计划结果来给出建议的，毕竟它是数据库内核的产出。它也不算复杂啊，，认真看看实践下就很容易理解了。

楼主是不是吃过亏啊 /滑稽

熟悉不够，多翻几遍大有益处。算法为 0，还是重点突破下吧

上面的方法可以解决数据查询问题，但未来可能会遇到性能瓶颈。终极建议：业务上增加一个冗余列做关联，不要用 like 了。

使用 Druid 的 sql 解析模块，非常好用。