DevCN开发者的创作与交流社区
RSS
菜单
社区成员个人主页
阿成员
DEV CN / 成员主页

阿青 · 社区话题账号

查看阿青 · 社区话题账号发布的技术文章、关注圈子与公开讨论。

0技术文章4关注圈子457圈内发布1关注者
登录后关注登录后私信
COMMUNITY POSTS

交流圈发布内容

作者在不同技术圈子中的观点与讨论

1
# MySQL

MySQL 大表 DDL 怎么安全执行？

问题：大表 ALTER（加列/改类型）在 8.0 前会锁表（copy table，阻塞读写）。方案：① 8.0 instant DDL：加列/加索引等支持秒级（ALGORITHM=INSTANT，只改元数据），首选；② INPLACE：8.0 大多数 DDL 支持 online（ALGORITHM=INPLACE, LOCK=NONE），不阻塞读写；③ 低版本/复杂 DDL：pt-online-schema-change（Percona…

2
# MySQL

MySQL 磁盘满、连接打满等故障怎么应急？

磁盘满：① 确认：df -h、错误日志（ER_DISK_FULL）；② 应急：清 binlog（PURGE BINARY LOGS BEFORE ...，先确认已备份）、清大临时文件（/tmp）、归档大表数据、扩容磁盘（云盘在线扩容）；③ 根治：监控告警（>80%）、日志保留策略。连接打满（1040）：① SHOW PROCESSLIST 找堆积原因（慢 SQL/锁等待）；② KILL 无用连接/慢查询（KILL id）；③ 临时调大…

5
# MySQL

MySQL 备份有哪些方式？mysqldump 和物理备份？

逻辑备份（mysqldump）：导出 SQL 语句——可跨版本/平台恢复、可选择性备份（表/库），但速度慢、恢复慢、一致性靠 --single-transaction（InnoDB 快照）；适合中小库、结构备份。物理备份（xtrabackup）：直接拷贝数据文件+日志——快、支持增量、在线备份（InnoDB 一致性由 redo log 保证），生产大库标准方案（Percona XtraBackup 8.0）。其他：快照（云盘/文件系统快…

6
# MySQL

MySQL 用户表和订单表怎么设计比较合理？

用户表：user_id BIGINT 主键（自增/雪花）、唯一索引（手机号/邮箱/用户名）、状态、注册时间、密码哈希（不存明文）、敏感字段加密；避免大字段（头像 URL、简介可拆 profile 表）；索引：登录查询字段加唯一索引。订单表：order_id 主键、user_id 索引（用户订单查询高频）、商户/商品冗余字段（反范式避免 JOIN）、金额 DECIMAL、状态字段（TINYINT 枚举+注释）、创建时间索引（按时间查询/归…

7
# MySQL

MySQL 金额字段应该用什么类型？为什么？

金额必须用 DECIMAL(M, D)（定点数，精确）：DECIMAL(18,2) 支持 10^16 数量级、精确到分（或 DECIMAL(20,4) 精确到万分之一）。禁止 FLOAT/DOUBLE：二进制浮点有精度误差（0.1+0.2≠0.3），金额累计/比较会出错。注意：① 大金额/多币种用 DECIMAL(20,4) 或扩展；② 分单位存储（BIGINT 存分）也是一种方案（整数运算最快），但展示转换易错；③ 计算在应用层或 S…

8
# MySQL

MySQL 时间字段用 DATETIME 还是 TIMESTAMP？

DATETIME：范围 1000-01-01 到 9999-12-31，8 字节，与时区无关（存储字面值，显示不变），推荐用于业务时间（下单时间、创建时间）——无时区坑、范围大。TIMESTAMP：范围 1970-2038，4 字节，存储 UTC（受时区影响，会话时区变显示变），有 2038 年问题；优点：省空间、可自动更新（ON UPDATE CURRENT_TIMESTAMP）——适合记录修改时间、时间戳语义字段。8.0 中两者均可…

9
# MySQL

MySQL 字段设计有哪些规范？varchar 长度怎么定？

① 类型最小化：能 TINYINT 不用 INT，能 INT 不用 BIGINT（省空间、索引小、缓存命中高）；② VARCHAR(N) 的 N 是字符数（utf8mb4 下最长 N*4 字节），按实际最大长度留余量（如姓名 50、URL 255、备注 500），过长用 TEXT；③ 定长高频列用 CHAR（如状态码、手机号 CHAR(11)）；④ 金额 DECIMAL(10,2)/DECIMAL(18,2)，禁止 FLOAT/DOUB…

10
# MySQL

MySQL 主键怎么设计？自增、UUID、雪花怎么选？

自增 BIGINT：插入有序（B+ 树顺序写、页不分裂）、空间小、简单——单库首选；缺点：分布式多写会冲突、可被遍历（安全敏感注意）、迁移合并麻烦。UUID：全局唯一、无中心——但 36 字符（可用 BINARY(16)/UUID_TO_BIN 优化）、无序导致随机 IO 与页分裂、索引性能差。雪花（Snowflake）：趋势递增、全局唯一、高性能——分布式场景推荐（分库分表、多机房）。实践：单库用自增 BIGINT；分库分表/分布式用…