非规范SQL的sharding-jdbc实践

小姐姐味道【ID：xjjdog】
作者：十年架构，日百亿流量经验，与你分享。

在《“分库分表” ？选型和流程要慎重，否则会失控》中，我们谈到处于驱动层的sharding-jdbc。开源做到这个水平，已经超棒了，不像tddl成了个太监。但还是有坑。

不过不能怪框架，毕竟有些sql，只有程序和鬼能懂。


    
        select          
           from order
           where  orderCode =  #{item}

不支持的操作

分库分表后，就成为了一个阉割型的数据库。很多sql的特性是不支持的，需要使用其他手段改进。以下以3.0.0版本进行描述。

distinct

sharding-jdbc不支持distinct，单表可使用group by进行替代。多表联查可使用exists替代

select DISTINCT
        a, b, c, d        from  table
        where df=0

改成

select a, b, c, d        from  table
        where df=0
        group by a, b, c, d

having

sharding-jdbc不支持having，可使用嵌套子查询进行替代

union

sharding-jdbc不支持union（all），可拆分成多个查询，在程序拼接

关于子查询

sharding-jdbc不支持在子查询中出现同样的表，如
以下可以⇒

SELECt COUNT(*) FROM (SELECt * FROM t_order o)

以下报错⇒

SELECt COUNT(*) FROM (SELECt * FROM t_order o WHERe o.id IN (SELECt id FROM t_order WHERe status = ?))

由于归并的限制，子查询中包含聚合函数目前无法支持。

mybatis 注释

sharding-jdbc不支持sql中的