说实话，看到Umami v3全面转向PostgreSQL的消息时，我第一反应是”终于等到了这一天”。这不仅仅是个数据库升级，更像是一场技术架构的”断舍离”。在实际迁移过程中，MySQL到PostgreSQL的转换真没想象中那么简单，光是数据类型映射就够让人头疼的。比如MySQL里的DATETIME直接转成PostgreSQL的TIMESTAMP看似没问题，但时区处理逻辑差异可能让历史数据的时间戳全乱套。
字符集问题最容易踩坑
记得有次帮客户迁移，测试环境跑得好好的，一到生产环境就出现中文乱码。排查半天才发现是MySQL默认用的latin1，而PostgreSQL严格要求UTF-8。这种隐性问题最麻烦，数据看起来导成功了，实际已经损坏了。现在我都会先用pgloader工具做预检，它能自动识别编码问题，省去了不少麻烦。
索引重建也是个技术活。MySQL的全文索引和PostgreSQL的GIN索引虽然功能相似，但语法和性能特征完全不同。有个项目迁移后查询速度慢得离谱，后来发现是没把MySQL的复合索引转换成合适的PostgreSQL部分索引。调整之后性能直接提升了五倍，你说这差距大不大？
存储过程和函数重写最耗时
最花时间的其实是存储逻辑迁移。MySQL的存储过程语法和PostgreSQL的plpgsql差别太大了，几乎要全部重写。有个统计模块的存储过程，在MySQL里运行只要200ms，刚开始迁移到PostgreSQL后竟然要2秒！后来优化了游标使用方式，才把性能拉回到正常水平。
外键约束的处理也需要特别注意。MySQL的ON DELETE CASCADE在PostgreSQL里表现不太一样，有次就遇到了循环删除导致的事务死锁。现在我都建议团队在迁移前先禁用所有外键，等数据验证完毕再逐个启用。
说真的，虽然迁移过程会遇到各种坑，但看到Umami v3在PostgreSQL上流畅运行的样子，还是觉得值了。特别是处理大量并发查询时，PostgreSQL的MVCC机制明显更稳定，不会再出现MySQL那种锁等待超时的情况了。
评论列表（7条）
终于等到这类实操经验分享了！
数据类型映射确实是个大坑，深有体会
pgloader工具记下了，下次迁移试试 👍
想问下存储过程重写大概花了多长时间？
外键约束这段太真实了，我也遇到过类似问题
从MySQL转PG后查询性能确实提升明显
中文乱码问题太常见了，感谢避坑指南