前言

从建表到SQL优化，让你少走三年弯路

前几天发表了一篇文章《一线大厂的Git规范》，在全网挺受欢迎的。

今天趁着打铁，跟大家一起聊聊一线互联网大厂的数据库规范，希望的对你会有所帮助。

有些大厂，几百上千人的研发团队，数据库却能保持井井有条。

表结构清晰、命名规范统一、索引设计合理、SQL性能可控。

很多经验还是非常值得借鉴的。

一、为什么大厂如此重视数据库规范？

前言

最近帮几个刚入行的朋友做技术指导，发现一个普遍现象：很多人从大学学完MySQL之后，就再也没碰过别的数据库了。

到了工作中，遇到一些复杂业务场景，用MySQL去硬撑，搞得焦头烂额。

说实话，PostgreSQL这几年在企业级应用中的普及速度非常快。

2026年DB-Engines排名显示，PostgreSQL稳坐全球第四大数据库的宝座，仅次于Oracle、MySQL和SQL Server。

今天，我就用一篇文章跟大家一起聊聊PostgreSQL，希望对你会有所帮助。

一、先说一个扎心的事实

有些小伙伴在工作中可能会说：“我用MySQL用了好几年了，感觉也挺好的啊，为什么要学PostgreSQL？”

我举个简单的例子：假如你的电商系统需要查询“2024年每个季度销售额排名前3的商品”，用MySQL写这个SQL起码20行起步，各种嵌套子查询、窗口函数疯狂套娃。

最近这两年，不管是做知识图谱还是智能推荐系统，或者 AI Agent 应用，图数据库这个词开始频繁出现在各种技术方案里。

有小伙伴跑来问：Neo4j 到底是什么？跟 MySQL 有啥区别？它能做什么？

我经常回答这样一句话：如果把数据比作一个社交关系网，MySQL 会用多个表格来描述这种关系，而 Neo4j 会直接画出这张网——节点就是人，线就是关系。

数据的本来面貌就是一张网，我们非要把网拆散了放到表格里，就是在做“破镜重圆”的事。

今天，我就用一个完整的入门教程，带你从头到尾搞懂 Neo4j。

希望对你会有所帮助。

一、Neo4j 到底是什么？

先说一个最核心的点，可能会打破你的认知——图数据库里的“图”，跟我们平时说的“图片”没有任何关系。

前言

在AI技术爆发的这两年，我发现了一个有趣的现象。

当大家都在讨论大模型有多强大时，真正落地的AI应用却往往卡在一个看似不起眼的环节：数据的检索和记忆。

你有没有想过，为什么智能客服能记住你之前的对话？

为什么电商推荐能精准找到“风格相似”的商品？

为什么企业知识库能瞬间从海量文档中找出你想要的答案？

这些能力的背后，都有一个共同的技术核心——向量数据库。

今天这篇文章就专门跟大家一起聊聊，AI中最常用的四种向量数据库，希望对你会有所帮助。

一、为什么AI离不开向量数据库？

有些小伙伴可能会问：传统的关系型数据库难道不能存储这些向量吗？

前言

对于后端开发同学来说，访问数据库，是代码中必不可少的一个环节。

系统中收集到用户的核心数据，为了安全性，我们一般会存储到数据库，比如：mysql，oracle等。

后端开发的日常工作，需要不断的建库和建表，来满足业务需求。

通常情况下，建库的频率比建表要低很多，所以，我们这篇文章主要讨论建表相关的内容。

如果我们在建表的时候不注意细节，等后面系统上线之后，表的维护成本变得非常高，而且很容易踩坑。

今天就跟大家一起聊聊，数据库建表的15个小技巧，希望对你会有所帮助。

前言

数据库和缓存（比如：redis）双写数据一致性问题，是一个跟开发语言无关的公共问题。尤其在高并发的场景下，这个问题变得更加严重。

我很负责的告诉你，该问题无论在面试，还是工作中遇到的概率非常大，所以非常有必要跟大家一起探讨一下。

今天这篇文章我会从浅入深，跟大家一起聊聊，数据库和缓存双写数据一致性问题常见的解决方案，这些方案中可能存在的坑，以及最优方案是什么。

1. 常见方案

通常情况下，我们使用缓存的主要目的是为了提升查询的性能。 大多数情况下，我们是这样使用缓存的：

1. 用户请求过来之后，先查缓存有没有数据，如果有则直接返回。
2. 如果缓存没数据，再继续查数据库。
3. 如果数据库有数据，则将查询出来的数据，放入缓存中，然后返回该数据。
4. 如果数据库也没数据，则直接返回空。

前言

说到MySQL数据库主从延迟问题，我还是深有体会的，因为我之前经常遇到。

我之前在一家餐饮工作公司中，当时我们的系统属于订单的下游业务系统。

在中午和晚上的用餐高峰期，用户并发量还是不小的。订单系统为了保证性能和高可用，做了主从分离架构。

一个主库，两个从库。

主库主要用来写数据，从库主要是用来读数据，主库的数据会实时同步到从库。

但偶尔会出现主从延迟问题。

1 案发现场

而我们划菜系统跟订单系统之间，是通过MQ进行通信的，流程如下：

前言

无论是开发、测试，还是DBA，都难免会涉及到数据库的操作，比如：创建某张表，添加某个字段、添加数据、更新数据、删除数据、查询数据等等。

正常情况下还好，但如果操作数据库时出现失误，比如：

1. 删除订单数据时where条件写错了，导致多删了很多用户订单。
2. 更新会员有效时间时，一次性把所有会员的有效时间都更新了。
3. 修复线上数据时，改错了，想还原。

还有很多很多场景，我就不一一列举了。

如果出现线上环境数据库误操作怎么办？有没有后悔药？

答案是有的，请各位看官仔细往下看。

1.不要用聊天工具发sql语句

通常开发人员写好sql语句之后，习惯通过聊天工具，比如：qq、钉钉、或者腾讯通等，发给团队老大或者DBA在线上环境执行。但由于有些聊天工具，对部分特殊字符会自动转义，而且有些消息由于内容太长，会被自动分成多条消息。

前言

最近在我的技术群里，有位小伙伴问了大家一个问题：如何保证Mongodb和数据库双写的数据一致性？

群友们针对这个技术点讨论的内容，引起了我的兴趣。

其实我在实际工作中的有些业务场景，也在使用Mongodb，也遇到过双写的数据一致性问题。

今天跟大家一起分享一下，这类问题的解决办法，希望对你会有所帮助。

1 常见误区

很多小伙伴看到双写数据一致性问题，首先会想到的是Redis和数据库的数据双写一致性问题。

有些小伙伴认为，Redis和数据库的数据双写一致性问题，跟Mongodb和数据库的数据双写一致性问题，是同一个问题。