"DBA 是个der" 吵出MySQL主键问题多种解决方案

上周五，因为MySQL的一个问题闹了点小争端，不过后面大家都理智，算是云淡风轻了。基于那个问题后面还有人说了自己公司的一个事情，算是引起我写这篇帖子的想法。

先说问题，各种异构的库，迁移到MySQL后的主键问题，我们先看一下原题。

上图中的问题，再次描述一下，在之前的SQL语句中，针对Oracle有 insert into table select sequence form 表，这里ORACLE ，PG 都有序列的概念，也就是我们产生一个序列，在插入的时候，我们调用序列来在插入数据的时候，自动进行自增或序列设置的数字递增的方式来进行数据的给出，且插入到表中。

但MySQL没有这个序列的概念，MySQL走的是在数据库底层设置整体的步长，且通过一列来进行数据的自增，那么这个怎么办。

简易方案：写函数，模拟一个自增的函数，在MySQL写一个函数，来进行自增，在语句中调用如

INSERT INTO your_table (id, column1, column2)
SELECT get_next_id(), column1, column2 FROM your_oracle_table;

CREATE FUNCTION get_next_id() RETURNS INT
BEGIN
   DECLARE new_id INT;
   SELECT COALESCE(MAX(id), 0) + 1 INTO new_id FROM your_table;
   RETURN new_id;
END;

这个部分在我看来是我目前用技术的方式，进行拼凑的一个方案，仅此而已，或者我们直接把这列空着，后面在补这个自增的数据也可，但具体是否可行 ，还的这个问的同学和他的技术人员自行决定。

而当时为什么“激情”给出了其他的方案，且造成群里早上的“动乱”，甚至引起其他的数据库大佬私信，问怎么回事。

其实我是想说说的，MySQL作为迁移目的地的问题，以及一些白痴领导，白痴的架构师，犯下的罪行。

1 ORACLE TO MySQL 是否合适，这是我想讨论的第一个问题

Oracle的数据组织是HEAP 表，也就是说Oracle的表本身可以没有主键，同时在一些工作的年头中，没有主键的表的确在早期一些公司存在，且常见。

Oracle的数据量承载的量级，尤其是单表，分区表等，可以承载的量是非常大的，MySQL基于他自己的数据承载物理结构，B+tree 表是非常不太适合进行单表承载几亿甚至更多的数据的。

Oracle支持复杂的查询语句的撰写和优秀的优化器，进行处理这些语句的执行，MySQL在这方面对比Oracle 差距较大。

写到这里就这三个问题，已经是系统运行中的，迁移Oracle TO MySQL后需要遇到的一些棘手，且难以解决的问题了，我就想问一句，主管数据库迁移的领导，或者主管这部分的架构师，你们从哪里得出结论，说ORACLE 迁移到MySQL是一个常用的方案，且成为前几年的一些主流方案。

为什么，你们解释一下？？？？ 你们解释不了，我给你你们说说你们可能且真实的想法

1 要名，不付出的人，这多见于一些领导，对于技术从来不关心，不知道那天从哪个其他的企业听闻，Oracle的政治问题，政策问题，反正影响他，官职和荣誉的问题，他要符合“潮流”，且把Oracle 替换掉，也不知道从哪里听了一耳朵，MySQL这个名字，且有些企业做过替换的事情，他就不管不顾，不闻不问，给下边人压力，换，把ORACLE 换了，用MySQL, 这样的事情估计不少，且很多人认为很正常。

2 架构师的无知，这样的架构师我见过，还不少，多见于某些，算了不说了要不打击面太大，这样的架构师生平，就懂俩数据库，ORACLE AND MySQL，这里并未说Oracle 不能迁移到MySQL，而是看基础，看可行性，需要评估后期的影响和改造的方式，比如有些公司或企业，他们进行了整体的改造，比如分库分表，逻辑分库，物理分库，使用中间件来进行，等等，虽然改造成本过大，但那是一个完整的方案，有些架构师无知到，就知道直接更换的程度，可能最近几年少了，之前这样的不少。

麻烦，架构师，架构师，你的见多识广，上到业务，下到基础组件的见识，如果你见识短，头发长，你还是干程序员比较合适，我见过太多的 DBA 被这样的架构师坑哭 ，对没错坑哭过，生不如死，且还的做背锅侠。咱们得具有反抗意识，不是说不让他办这个蠢事情，而是你的让他知道最后的代价，且让他也顺不了心，这里牵扯到人生哲理，不多言了，弱者之所以弱，还是自己不强，厉害的DBA ，架构师他敢。

这里也附带一下，Oracle到MySQL的主键一些处理和设计上的技术方案，也不枉我，骂粗制滥造的架构师一顿。

ORACLE TO MySQL主键方案1：

这里必须得讨论业务，不讨论业务进行数据库迁移，那就有点精神病院出来的“科学家”，先看业务，看表，是否可以存在一个列，自增列，且这个自增列与业务无关，完全是为了MySQL的物理特性而建立的主键，查询基本上用不到。（查询语句也不要是select * from table ,否则这个方案失效）

ORACLE TO MySQL主键方案2：

联合主键，我相信即使你用ORACLE ，也不可能让ORACLE的表裸奔，没有任何去重的字段，哪怕是联合的，那么能去重的字段，或者联合的字段就是你的MySQL的主键，虽然效率不高，但最起码你有主键了。（注意字段的数量和字段的类型）

ORACLE TO MySQL主键方案 2 升级版

联合主键变为一个字段，通过算法，举例如MD5或者sha256等，或者自己写雪花算法也可，将这些字段的值进行合并计算，成为一个新的字段，这个字段就是新的主键，这个就需要进行程序的略微改造了，比如你的有把几个字段进行合并运算的部分，且将这个值插入到主键中，而这个主键就可以和业务关联了。（好处是自然，多逻辑字段但实际上就一个字段做物理主键）

ORACLE TO MySQL主键方案 3

雪花有序算法，这个多见于物理分库的情况下，常常使用，主键就赋予更重要的意义，包含了寻址数据的意义，所以算法必须是产生唯一值，且不撞KEY的，至于什么算法，架构师们，你们的活。

ORACLE TO MySQL 主键方案 3 变种

写函数，对在MySQL中写函数，通过函数来产生值，也就是你给函数一个值，函数给你算出一个主键，今天上面的方案就是这个方案，通过获取当前表的最后一个值，我们在插入的时候，将值+1 ，然后插入来模拟ORACLE 的序列。

ORACLE TO MySQL 主键方案 4 ...... 就写到这吧，回来让架构师都学了去，在“欺负” DBA。

其实5群里，一个同学的在：“激烈的” 沟通中，说了一句话，我简单描述一下，“架构师认识你 DBA 是个der”

这里我知道这个想法的人，应该有一定数量集，我想回复的是，任何时候，自己不强，谁都可以欺负你，国家如此，城市如此，人也如此。

架构师不是高高在上，DBA 也不是贫贱如屎，市面上的数据库抄起来，你都会点，懂点，有方案，你比架构师在数据库方面知道的还多，他不会欺负你，他过来请教你还来不及呢！

但凡DBA 会点 PostgreSQL , Oceanbase, 达梦， 咱们也不会随便被迁移ORACLE 的问题词穷！ 人穷志短，知识少，也一样的短！！人类社会再高级，再文明，始终是拳头说话，实力说话，能力说话。