一哥，麻烦回答一下你自己提的两个问题吧
如题，是一哥你自己提的问题哈哈。也是到目前为止，你提过的我印象很深的两个问题。
- 优惠券系统中使用的是提前生成的优惠券码，保证了编码不重复且编码有意义。
你的问题是：如果是动态生成优惠券码的话应该如何实现呢？我在群里见过别人说的方式都是保证唯一性(UUID呀，雪花呀乱七八糟的)。但是都会丢失编码中可包含的意义。我感觉你字里行间的意思还是这两者可以兼顾的。
一哥，你对这个问题的官方答案是什么呢？ - MySQL专栏中。分库分表那一块，说到user表按照user_id水平拆分后的查询问题。
user 表拆分之后，如果我想用 user_name、email、phone 去查询用户信息，怎样做效率会高呢 （注意，数据分布在多个库、多个表中，轮询自然是不合理的）？
我的问题是：怎么做效率会高呢（注意，数据分布在多个库、多个表中，轮询自然是不合理的）？ - 老勤，你休假了吗？
正在回答
1回答
宇文老师你好：
我不得不说，你这里提出的两个问题质量都非常的高，哦，不，是我自己提出的两个问题。当然了，能给宇文老师留下深刻的印象，我也是很欣慰的。我这里首先回复你的第三个问题：我近期大概率不会休假。
第一个问题，如何动态的生成优惠券码，且不丢失编码中包含的意义。
不错，这个问题问的非常好。我们先来辩证一下，分布式 id 生成算法可行吗？我认为：可行但不是最优解。可行的原因很简单，因为只要优惠券码是唯一的就可以了。但是，这样做无疑会丢失优惠券码中涵盖的业务意义。那么，怎么做呢？简而言之就是：区间分段。看以下的详细步骤说明：
（1）我们首先需要一个注册中心，我们的服务都需要注册中心知晓
（2）我们部署的每一个实例都会注册到注册中心，那么，注册中心就可以给每一个实例分配它所能分配的 id 区段，例如：A 实例分配 11 ~ 20，B 实例分配 21 ~ 30，等等依次类推，这样既可以保证优惠券码中包含有业务含义，也能够保证优惠券码是唯一的，且不会导致优惠券超发
那么，问题来了，这样做，会有可能导致某个实例已经分配完了，而另外的实例还有优惠券分配的额度。这个问题其实很简单，也有两种处理策略去应对：
（1）忽略这个问题，就是你有时候会看到的，明明看到 app 上显示还有余票，但是，点击购买的时候，告诉你已经销售光了，那么，其实就是直接忽略了。这不会有什么问题，只是你买不到了，而实际上肯定会有人能够成功购买（这就是传说中的看运气了）
（2）因为各个实例有统一的注册中心，所以，你的实例可以转发到还有库存的实例上去，让其他的实例来生成优惠券码。但是，这样做，无疑会有很多工作量，例如：请求转发、实例生成优惠券码的记录等等。
不过，这个系统仍然不够完善，动态生成优惠券的区间分段分配只是最理想的情况，但是，如果某个实例挂了，一部分优惠券码没有分配成功，就会导致库存不能被完全消耗。这还需要做补发相关的逻辑。等等类似的复杂问题还有很多，所以，我最终建议你：静态生成，至少我见过的优惠券系统都是静态生成的。
第二个问题，这个问题其实很简单了，你说的是有道理的，当然是可以根据 username、email、phone 去查询用户信息。最好的办法就是索引，即建立索引表。这里可以建立三张索引表：
（1）user_id、username 构成一张表
（2）user_id、email 构成一张表
（3）user_id、phone 构成一张表
即使你有十亿条数据，这么简单的表结构查询都是非常快的，且存储也是最小的消耗。我相信宇文老师应该理解老勤的意思啦！
我是勤一，致力于将这门课程的问答区打造为 Java 知识体系知识库，Java 知识体系 BBS！共同建造、维护这门课程，我需要每一个你！
