UUID_SHORT()是MySQL内置的替代方案，其64位整数结构类似雪花ID，高32位为server_id，避免了触发器中实现雪花ID时的时间精度不足、机器标识缺失、并发冲突等问题。
MySQL触发器里没法直接生成标准雪花ID
因为雪花ID（Snowflake ID）依赖毫秒级时间戳、机器ID、进程ID和序列号的位运算组合，而MySQL原生不提供纳秒级时间精度、无法获取本机网络标识、也没有安全的全局自增序列计数器。你如果在BEFORE INSERT触发器里硬写一个“模拟雪花ID”的函数，大概率会遇到重复、时钟回拨、并发冲突或溢出问题。
用UUID_SHORT()替代是最现实的方案
UUID_SHORT()是MySQL内置函数，返回一个64位无符号整数，结构接近雪花ID：高32位是server_id ，低32位是自增序号。它不需要额外配置，支持并发插入，且天然唯一（只要<code>server_id不重复、时间不倒流）。
- 确保
server_id已设置（比如在my.cnf中配server-id = 123），否则所有实例生成的ID可能撞车 - 它不是严格单调递增的——同一秒内多条记录的ID大小取决于插入顺序，但对大多数业务索引场景影响不大
- 避免在主从复制中混用不同
server_id的写入节点，否则从库回放时UUID_SHORT()值会变
真要强一致性雪花ID，得把生成逻辑移出MySQL
推荐在应用层（如Python/Java/Go）调用成熟库生成，再作为普通字段传入INSERT语句。例如Python用python-snowflake，Java用twitter-snowflake或idworker。这样能精确控制机器ID分配、序列号重置、时钟回拨补偿等细节。
- 不要在触发器里调用
SYS_EVAL或UNHEX拼接字符串再转数字——这既慢又不可靠 - 别用
NOW()加毫秒级UNIX_TIMESTAMP(1234567890123)手动算时间戳——MySQL的UNIX_TIMESTAMP()只到秒级，SYSDATE(3)虽支持毫秒但无法保证跨会话单调 - 如果必须存进MySQL，字段类型必须是
BIGINT UNSIGNED，否则超过9223372036854775807会溢出变负数
临时应急：用触发器+REPLACE INTO+自增ID模拟低位序列
仅限测试或低并发场景。建一张辅助表记录每秒的序列值，用REPLACE INTO ... SELECT抢锁更新，再结合UNIX_TIMESTAMP(NOW())左移拼接。但这会严重拖慢写入性能，且在高并发下极易死锁。
CREATE TABLE snowflake_seq ( ts_sec INT PRIMARY KEY, seq INT DEFAULT 0 ) ENGINE=InnoDB;
触发器里先REPLACE INTO snowflake_seq VALUES (UNIX_TIMESTAMP(NOW()), 0)，再SELECT seq FROM snowflake_seq WHERE ts_sec = UNIX_TIMESTAMP(NOW())——但这个读写分离本身就不可靠，别在线上用。
真正稳定的雪花ID生成，从来不在数据库里做。触发器能做的只是兜底校验或简单整形，核心生成逻辑必须交还给有状态管理能力的应用层或独立ID服务。
