背景：
最近，在组织公司业务数据库的迁移与拆分工作。时常需要从数据库层面，去判断是否尚有应用在连接数据库？连接的ip有哪些？从而根据ip，定位到具体的应用，找到责任人。
应用访问数据库的架构无非分为两种：直连方式与通过中间件方式。
下面就这两种方式进行总结。
一、直连方式
需求：数据库schema拆分，对其中一部分schema迁移，一部分不迁移。
迁移走的schema，增设绑定vip。应用修改对应的数据源为vip，修改完以后统一切换vip到新环境。
难点：同一台应用机器上，部署多个应用，部分连接不迁移的schema，部分连接迁移的schema（vip）,这样导致无法检测哪些需要迁移的schema，到底有没有修改成vip。
方式：
1）、准备schema迁移列表
2）、在db线程中匹配访问每个schema的所有host:id列表。
3）、根据host:id列表，检索netstat中对应的host:id
4）、在netstat中所有通过非VIP连接的，都是漏改的。
（对于短时间内的线程id，相对比较准确）
二、前端使用中间件
需求：部分schema已经迁移走（schema还没删），但是从数据库 general_log 日志中，发现还有应用在查询这些schema中的表。现在要找到哪些应用来查询这些schema？
难点：由于数据库前端，使用了中间件cobar，同时使用了haproxy等组件。导致从数据库processlist 中只能看到cobar的ip地址。haproxy中配置了cobar的地址。 从haproxy里能看到ip，但是看不到访问哪些schema。
方式：从数据库 general_log日志入手。
1）、开启 general_log 日志，找到已经迁移走的schema中的表。
2）、根据该条日志的第一个值：线程id， 在general_log中查找该线程id。
3）、分析查找的结果，找出其他比较熟悉的表名，最好根据这些表名能一看就看出业务归属。
