MySQL主键
主键使用自增ID还是UUID?能说说原因吗？
自增ID和UUID作为主键的考虑主要有两方面，
一个是性能
另一个就是存储的空间大小，
一般没有特定的业务要求都不推荐使用UUID作为主键。
因为使用UUID作为主键插入并不能保证插入是有序的，有可能会涉及数据的挪动，也有可能触发数据页的分裂，因为一个数据页的大小就是16KB，这样插入数据的成本就会比较高。
而自增ID作为主键的话插入数据都是追加操作，不会有数据的移动以及数据页的分裂，性能会比较好。
另一方面就是存储空间，
自增主键一般整形只要4个字节，长整形才占8字节的大小空间，
而使用UUID作为主键存储空间需要16字节的大小，会占用更多的磁盘，
在二级索引中也会存出一份主键索引，这样多占用消耗的空间就是两倍，性能低，
所以不推荐使用。
自增id是连续的，插入过程也是顺序的，总是插入在最后，减少了页分裂，有效减少数据的移动。
所以尽量不要使用字符串（如：UUID）作为主键。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Michael's Blog！
相关推荐
2019-04-20
MySQL 数据类型选型
一句话 选最小的、能装下你数据的类型。 类型小 = 索引小 = 内存命中率高 = 快。 一、整数类型 类型 字节 范围（无符号） 用途 TINYINT 1 0 ~ 255 状态枚举、布尔 SMALLINT 2 0 ~ 65535 较小计数 MEDIUMINT 3 0 ~ 1677w 较少用 INT 4 0 ~ 42亿 大多数主键、ID BIGINT 8 0 ~ 1844亿亿 雪花 ID、大表主键 1234-- ❌ 用户性别用 INTgender INT-- ✅ 用 TINYINTgender TINYINT UNSIGNED COMMENT '0未知 1男 2女' INT(11) 里的 11 不是长度！只是显示宽度（已废弃），实际仍是 4 字节。 二、字符串类型 类型 长度 适用 CHAR(n) 固定 n 字符 MD5、UUID、固定位手机号 VARCHAR(n) 可变 ≤ n 大多数字符串 TEXT (4 种) 长文本 文章正文，不要建普通索引 ENUM 枚举 不推荐，...
2021-03-20
MySQL - 锁
[TOC] 锁机制 计算机协调 多个进程或线程 并发访问某一资源的机制。 锁的类型及其特点开销、加锁、颗粒度、冲突、并发等角度分析 表级锁(table-level locking) 开销大，加锁快，不会出现死锁，颗粒度大，锁冲突概率高，并发度小； 页面锁(page-level locking) 开销、加锁效率、颗粒度介于表锁和行锁之间，会出现死锁，并发度一般； 行级锁(row-level locking) 开销大，加速慢，会出现死锁，颗粒度小，锁冲突概率小，并发度高； 锁的类型应用场景表锁 - 适合 以查询为主，只有少量按索引条件更新数据的应用，如web应用； 行锁 - 适合 大量按索引条件并发 更新少量不同数据，同时又有并发查询的应用，如在线事务处理系统； 锁的支持度及情况MyISAM 只支持 表锁 InnoDB 默认支持 行锁，也支持表锁 12-- 查询表锁争用情况show status like 'table%'; # Table_locks_waited 大则表锁争用情况严重 锁的维度划分共享锁(S) - 读锁 排他锁(X) - 写锁 意向共享锁...
2022-05-20
MySQL优化经验总结
线上SQL的调优经验 slow_query_log 日志中收集到的慢 SQL ，结合 explain 分析是否命中索引。 减少索引扫描行数，有针对性的优化慢 SQL。 建立联合索引，由于联合索引的每个叶子节点包含检索字段的信息，按最左前缀原则匹配后，再按其它条件过滤，减少回表的数据量。 还可以使用虚拟列和联合索引来提升复杂查询的执行效率。 监控sql执行情况，发邮件、短信报警，便于快速识别慢查询sql 打开数据库慢查询日志功能 简化业务逻辑 代码重构、优化 异步处理 sql优化 索引优化 SQL优化 分页优化。比如电梯直达，limit 100000,10 先查找起始的主键id，再通过id>#{value}往后取10条 尽量使用覆盖索引，索引的叶节点中已经包含要查询的字段，减少回表查询 SQL优化（索引优化、小表驱动大表、虚拟列、适当增加冗余字段减少连表查询、联合索引、排序优化、慢日志 Explain 分析执行计划）。 where子句 避免对字段进行null值判断、表达式操作等； where表之间的连接，必须写在其他where条件之前...
2020-03-20
MySQL三范式
数据库三范式 第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解； 第二范式：2NF是对记录的唯一性约束，要求记录有唯一标识，即实体的唯一性； 第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。 范式化 优点：可以尽量的减少数据冗余，使得更新快，体积小 缺点：对于查询需要多个表进行关联，减少写的效率增加读的效率，更难进行索引优化 反范式化 优点：可以减少表的关联，可以更好的进行索引优化 缺点：数据冗余以及数据异常，数据的修改需要更多的成本 归纳 方式 第一范式 第二范式 第三范式 约束 原子性 唯一性 冗余性 优点 更新快 体积小 减少数据冗余 缺点 对于查询需要多个表进行关联 减少写的效率增加读的效率 更难进行索引优化 (反)优点 可以减少表的关联 可以更好的进行索引优化 - (反)缺点 数据冗余以及数据异常 数据的修改需要更多的成本 -
2020-03-20
MySQL事务
事务概念 4个原则 ACID 原则 概念 原子性 一个事务中的操作要么全部成功，要么全部失败 Atomicity 一致性 总是从一个一致性的状态转换到另一个一致性的状态 Consistent 隔离性 一个事务的修改在提交前，其他事务是感知不到的 Isalotion 持久性 永久保存在数据库中 Durable 原子性、隔离性、持久性都是为了保障一致性而存在的，一致性也是最终的目的。 隔离级别 读未提交 READ UNCOMMITTED 读已提交 READ COMMITTED 可重复读 REPEATABLE READ 可序列化 SERIALIZABLE 没有那种隔离级别是完美的，只能根据自己的项目业务场景去评估选择最适合的隔离级别，大部分的公司一般选择Mysql默认的隔离级别：可重复读。 隔离级别从：读未提交-读提交-可重复读-串行化，级别越来越高，隔离也就越来越严实，到最后的串行化，当出现读写锁冲突的时候，后面的事务只能等前面的事务完成后才能继续访问。 读未提交：读取到别的事务还没有提交的数据，从而产生了脏读。 读提交：...
2019-05-10
索引的优缺点
一句话 索引以”读快、写慢、占空间”为代价换查询性能。 加索引前先想：这字段查得多吗？选择性够不够？ 一、优点 优点 说明 加速 WHERE 查询 从 O(N) 全表扫描 → O(log N) B+ 树查找 加速 ORDER BY / GROUP BY 索引天然有序，省去 filesort 加速 JOIN 关联字段有索引时大幅提速 唯一索引保证唯一性 数据约束 + 查询双重价值 覆盖索引免回表 二级索引就能返回所有需要的列 二、缺点 缺点 说明 量化 占空间 每个索引都是一棵 B+ 树 一个 INT 索引在 100w 行表上约 30MB 写入变慢 INSERT/UPDATE/DELETE 都要维护所有相关索引 每多一个索引，写入慢 5-15% 优化器选错索引 索引太多反而干扰优化器 用 FORCE INDEX 兜底 维护成本 在线加索引要锁表/影响性能 大表用 pt-online-schema-change 三、加索引的判断标准✅ 该加： WHERE / ORDER BY...
评论
