LoveCTO从0开始搭建后台管理系统，这是No9。上一篇我们讲到了：一个数据库表应该有哪些字段？。这一节，我们就来创建第一个数据库表。
创建用户表
建表语句如下：
CREATE TABLE `sys_user` (
`id` bigint NOT NULL COMMENT '用户ID',
`user_name` varchar(32) NOT NULL COMMENT '用户名',
`password` varchar(255) NOT NULL DEFAULT '' COMMENT '密码',
`nick_name` varchar(32) NOT NULL COMMENT '昵称',
`email` varchar(64) DEFAULT NULL COMMENT '邮箱',
`mobile` varchar(16) DEFAULT NULL COMMENT '手机号',
`sex` int DEFAULT NULL COMMENT '性别',
`avatar` varchar(255) DEFAULT NULL COMMENT '头像',
`remark` varchar(255) DEFAULT NULL COMMENT '备注',
`status` int NOT NULL DEFAULT '1' COMMENT '状态(1启用，0停用)',
`create_time` datetime NOT NULL COMMENT '创建时间',
`update_time` datetime NOT NULL COMMENT '修改时间',
`creater` bigint DEFAULT NULL COMMENT '创建人',
`updater` bigint DEFAULT NULL COMMENT '修改人',
`deleted` bit(1) NOT NULL DEFAULT b'0' COMMENT '删除状态:1已删除，0未删除',
`version` int NOT NULL DEFAULT '1' COMMENT '版本',
`tenant_id` int NOT NULL DEFAULT '0' COMMENT '租户',
PRIMARY KEY (`id`),
UNIQUE KEY `user_name` (`user_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
关于ID的生成策略
数据库主键ID的生成策略有：自增ID、雪花ID、UUID等策略。
1. 自增ID（Auto-Increment ID） 原理
由数据库（如MySQL、PostgreSQL）自动生成，基于序列（Sequence）或自增列实现，每次插入时ID值+1（步长可配置）。
优点
- 极致简单 ：无需额外代码实现，数据库原生支持，开发成本极低。
- 性能优异 ：自增特性保证了ID的连续性，数据库索引（如B+树）插入效率高，不会产生索引碎片。
- 有序性强 ：ID按时间顺序递增，便于按创建时间排序和范围查询（如 WHERE id > 100 AND id < 200 ）。
- 存储空间小 ：通常使用 BIGINT （8字节）或 INT （4字节）类型，占用空间小。 缺点
- 分布式环境不友好 ：单库自增ID无法跨数据库实例保证唯一性，在分库分表场景下需要额外的分布式ID生成机制（如应用层分配区间）。
- 安全风险 ：ID的连续性容易泄露业务数据量（如订单ID从1001增长到2001，可推测日订单量约1000），也可能被恶意猜测其他记录的ID。
- 扩展性受限 ：受限于数据库类型和配置（如MySQL的 AUTO_INCREMENT 有上限），且跨库迁移时可能出现ID冲突。 适用场景
- 单库单表或简单分库分表（可通过应用层分配ID区间解决）的系统。
- 对性能要求极高、数据量中等的业务（如内部管理系统）。
- 不关心ID泄露业务信息的场景。
2. 雪花ID（Snowflake ID） 原理
由Twitter开源的分布式ID生成算法，基于 时间戳+机器ID+序列号 的64位二进制结构：
- 1位：符号位（固定为0，保证ID为正数）。
- 41位：时间戳（毫秒级，可支持约69年）。
- 10位：机器ID（可部署1024个节点）。
- 12位：序列号（同一毫秒内同一机器可生成4096个ID）。 优点
- 分布式友好 ：支持多节点并行生成ID，天然解决分库分表场景的ID唯一性问题。
- 有序性强 ：ID按时间戳递增，局部有序（同一机器、同一毫秒内有序），索引插入性能接近自增ID。
- 性能优异 ：纯内存生成，无网络IO，TPS可达百万级，适合高并发场景。
- 可定制性 ：可根据业务需求调整各部分的位数（如机器ID位数、时间戳位数）。 缺点
- 依赖系统时间 ：若系统时间回拨（如时钟同步错误），可能导致ID重复或生成旧ID。
- 实现复杂度高 ：需要开发和维护分布式ID生成服务，增加系统复杂度。
- 机器ID管理 ：需要确保机器ID的唯一性（如通过配置中心或ZK分配），否则可能导致ID冲突。 适用场景
- 高并发分布式系统（如电商订单、支付交易）。
- 分库分表场景，需要全局唯一ID的系统。
- 对ID有序性有要求的业务（如按创建时间排序）。
3. UUID（Universally Unique Identifier） 原理
通用唯一识别码，基于RFC 4122标准生成的128位唯一标识符（通常表示为32位十六进制字符串，如 550e8400-e29b-41d4-a716-446655440000 ）。常见版本：
- UUID v1 ：基于时间戳+MAC地址（存在隐私风险）。
- UUID v4 ：基于随机数（最常用，全局唯一概率极高）。 优点
- 全局绝对唯一 ：理论上UUID重复的概率极低（可忽略不计），无需考虑分布式环境的ID冲突。
- 无中心化依赖 ：客户端/应用层即可生成，不依赖数据库或其他服务，降低系统耦合。
- 部署简单 ：无需额外服务或配置，开发成本低。 缺点
- 性能较差 ：UUID是随机字符串，插入数据库时会导致B+树索引频繁分裂（产生大量索引碎片），查询和插入性能明显低于自增ID/雪花ID。
- 存储空间大 ：128位（16字节），远大于自增ID（8字节），增加存储成本。
- 无序性 ：UUID v4完全随机，无法通过ID判断创建时间，不适合按时间排序的场景。
- 可读性差 ：长字符串形式（如 550e8400-e29b-41d4-a716-446655440000 ），不利于人工排查和调试。 适用场景
- 对ID唯一性要求极高，但不关心性能和有序性的场景（如日志ID、临时表记录）。
- 无中心化部署的系统（如客户端本地数据存储）。
- 不需要通过ID进行时间排序或范围查询的业务。
如何选择？
- 单库单表/低并发 ：优先选择 自增ID （简单、性能好）。
- 分布式高并发 ：优先选择 雪花ID （分布式友好、性能优、有序）。
- 无中心化/不关心性能 ：选择 UUID （全局唯一、部署简单）。
在我们这个项目中，计划选择雪花ID实现。
