1.非分片字段查询
分片字段和分片方法来确定的。例如下图中的一个Mycat分库方案：
- 根据 tt_waybill 表的 id
- 分片方法为 id 值取 3
id
id
此时Mycat会计算路由结果
12330 % 3 = 0 –> DB1
并将该请求路由到DB1上去执行。
如果查询条件中没有 分片字段
mysql>select * from tt_waybill where waybill_no =88661;
此时Mycat无法计算路由，便发送到所有节点上执行：
DB1 –> select * from tt_waybill where waybill_no =88661;
DB2 –> select * from tt_waybill where waybill_no =88661;
DB3 –> select * from tt_waybill where waybill_no =88661;
如果该分片字段选择度高，也是业务常用的查询维度，一般只有一个或极少数个DB节点命中（返回结果集）。示例中只有3个DB节点，而实际应用中的DB节点数远超过这个，假如有50个，那么前端的一个查询，落到MySQL数据库上则变成50个查询，会极大消耗Mycat和MySQL数据库资源。
如果设计使用Mycat时有非分片字段查询，请考虑放弃！
2.分页排序
先看一下Mycat是如何处理分页操作的，假如有如下Mycat分库方案：
一张表有30份数据分布在3个分片DB上，具体数据分布如下
DB1：[0,1,2,3,4,10,11,12,13,14]
DB2：[5,6,7,8,9,16,17,18,19]
DB3：[20,21,22,23,24,25,26,27,28,29]
（这个示例的场景中没有查询条件，所以都是全分片查询，也就没有假定该表的分片字段和分片方法）
当应用执行如下分页查询时
mysql>select * from table limit 2;
Mycat将该SQL请求分发到各个DB节点去执行，并接收各个DB节点的返回结果
DB1: [0,1]
DB2: [5,6]
DB3: [20,21]
[0,1]，如果Mycat最先收到DB2节点的结果集，那么返回给应用端的结果集为 [5,6]。也就是说，相同情况下，同一个SQL，在Mycat上执行时会有不同的返回结果。
在Mycat中执行分页操作时必须显示加上排序条件才能保证结果的正确性，下面看一下Mycat对排序分页的处理逻辑。
假如在前面的分页查询中加上了排序条件（假如表数据的列名为id）
order by id
Mycat的处理逻辑如下图：
[0,1]
偏移量
limit 5,2;
如果按照上述排序分页逻辑来处理，那么处理结果如下图：
[10,11], [16,17], [20,21] 经过最小堆计算后返回给应用的结果集是 [10,11]。可是，对于应用而言，该表的所有数据明明是 0-29 这30个数据的集合，limit 5,2 操作返回的结果集应该是 [5,6]，如果返回 [10,11]则是错误的处理逻辑。
有偏移量的排序分页 时是另外一套逻辑——改写SQL
limit m,n 的SQL语句时会对其进行改写，改写成 limit 0, m+n
mysql>select * from table order by id limit 0,7;
各个DB返回给Mycat的结果集是
DB1: [0,1,2,3,4,10,11]
DB2: [5,6,7,8,9,16,17]
DB3: [20,21,22,23,24,25,26]
[0,1,2,3,4,5,6] ，然后返回偏移量为5的两个结果为 [5,6]
t 个DB节点的全分片 limit m, n 操作，Mycat需要处理的数据量为 (m+n)*t 个。比如实际应用中有50个DB节点，要执行limit 1000,10操作，则Mycat处理的数据量为 50500 条，返回结果集为10，当偏移量更大时，内存和CPU资源的消耗则是数十倍增加。
如果设计使用Mycat时有分页排序，请考虑放弃！
3.任意表JOIN
player 和 team 两张表，player 表中的 team_id 字段与 team 表中的 id
JOIN操作的SQL如下
mysql>select p_name,t_name from player p, team t where p.no = 3 and p.team_id = t.id;
此时能查询出结果
p_name | t_name |
Wade | Heat |
如果将这两个表的数据分库后，相关联的数据可能分布在不同的DB节点上，如下图：
这个SQL在各个单独的分片DB中都查不出结果，也就是说Mycat不能查询出正确的结果集。
设计使用Mycat时如果要进行表JOIN操作，要确保两个表的关联字段具有相同的数据分布，否则请考虑放弃！
4.分布式事务
XA事务，而是只保证 prepare 阶段数据一致性的 弱XA事务
应用开启事务后Mycat标识该连接为非自动提交，比如前端执行
mysql>begin;
Mycat不会立即把命令发送到DB节点上，等后续下发SQL时，Mycat从连接池获取非自动提交的连接去执行。
Prepare Ready 状态，如果有一个节点执行失败，则标识为 Rollback
commit 或 rollback 命令。发送 commit 命令时，Mycat检测当前连接是否为 Prepare Ready 状态，若是，则将 commit
commit 时故障，而其他DB节点 commit 成功，Mycat会一直等待故障DB节点返回结果。Mycat只有收到所有DB节点的成功执行结果才会向前端返回 执行成功 的包，此时Mycat只能一直 waiting 直至TIMEOUT，导致事务一致性被破坏。
设计使用Mycat时如果有分布式事务，得先看是否得保证事务得强一致性，否则请考虑放弃！
