1、场景今天，看到了时钟一样的场景。 表名叫award_use_risk，作用是记录奖品的使用记录，由作风控制。 表的结构如下。
这张表只是一个库，没有表。 数据库分为四个库，每个库都是db0-db4。
我的第一个反应是根据terminal no或prize guid，具体查看业务逻辑进行分表操作。 这使添加、修改和删除可以通过分片算法放置在任何库中。
之后，需要查看业务场景中，定时删除前一天的风力发电控制数据。 在这种情况下，条件中只有时间，没有分片密钥。 如何配置每个库？
整理一下：
根据prize guid进行分片路由。 例如，prize guid24/256的结果为0-3，正好我们是四个库。 没问题。如果删除前一天的所有风力发电记录，该怎么办？ 此时没有prize guid。 怎么瓷砖化？ 大约昨天，deletefromaward _ use _ riskwheregmt _ create要求此sql语句在每个库中执行一次，且不能路由。 因为路由不知道运行的是哪个库，哪个库没有运行。 2、为了确定删除思路时在哪个库，我们不能使用prize guid，只能用确定的数字0-3查找每个库运行一次。 那样的话，我们的瓷砖根键必须是确定范围的数字。 0、1、2、3，将其称为data id。
删除时，可以通过运行for循环并传递0、1、2和3来轮询和删除每个库的前一天的数据。
那么插入呢？ 我们需要使用data id，针对每个风控记录生成这个data id。 我们根据prize guid24/256计算data id，进行分库分表。 好的。
3、共同问题上面的案例可以通过冗余字段解决，但是对于一些不带分片键的条件查询，并不是通用方案，我们一起看看非分片键过滤，如何解决：
例如，根据订单表单orders、一般SQL等状态和时间范围进行查询。
方案1 )直接查询这样的优点代码简单，但缺点很明显。 在没有分片字段的情况下，中间件不知道数据具体位于哪个分片上，因此它将同时向所有分片数据库发送查询sql，显著降低数据库性能，严重影响核心业务对数据库的需求虽然可以创建适当的索引以提高性能。
场景2 :通过指定数据库节点并导入Mycat，可以指定数据库节点。 多线程读取每个数据节点，从而提高性能，但效果不好。
方案3 :异构索引、空间交换时间计算机领域的问题可以通过分期治疗或增加一个层次来解决。 这个问题是，我们为了提高效率，加大了空间，比如把订单信息表分库分表后，为了查询购买者的订单，需要根据购买者id进行查询，显然不走瓷砖键，所以
修改订单时，另行建立表格。 该表按购买者id分类，查询时从购买者id查询到订单id，然后前往订单表查找订单信息。 流程如下：
这个方案很好，但不通用。 如果我们根据时间、状态等信息进行咨询怎么样？
方案四：实时数仓我的想法是拦截数据库的变化，可以实现很多中间件(Canal Kafka )，根据数据库的binlog
实时创建数据仓库，将数据放在一起，方便查询，避免了按库列出的表带来的复杂性。
4、分库分表弊端1.事务支持
拆分表时，它是分布式事务。 如果依赖数据库本身的分布式事务管理功能来执行事务，则需要较高性能成本的APP应用程序配合控制，形成程序的逻辑事务，这将增加编程负担。
2.复杂查询
分割表后，就无法进行连接操作。 查询禁止查询未拆分的维。 即使中间件支持此查询并可以在内存中进行组装，但这种需求往往不应该在在线库查询中实现，或者可以通过其他方式转换为拆分的维。
解决这个问题的一些方法：
全局表
全局表也可以看作'数据字典表'。 这是系统中所有模块都可能依赖的表。 为了避免库之间的连接查询，可以使用这类表在每个数据库中都保存一份。 这些数据通常是
因为很少修改，所以也不担心一致性的问题。
字段冗余
在利用空间换时间，为了性能而避免join查询/订单表中保存userId时，也可以将userName冗馀化保存，这样在详细了解订单时就不需要查看“购买者user表”。
数据组装
在系统层面，分两次查询从第一个查询的结果集中找到相关数据id，并根据id启动第二次请求以获取相关数据。 将最后得到的数据组合到字段中。
评论：
1 .当前，营销中心分类表后的id将id的next value记录在一个数据库的sequence表中，而不是雪地算法中，以避免全局重复。 配置如下：
2 .营销中心非瓷砖密钥查询？