数据库正在成为AI原住民上周帮朋友看一个数据分析需求，他问我："能不能直接用中文问数据库问题，不用写SQL那种？"我说当然可以，但要加个中间层，用LangChain或者别的什么。他愣了一下："这么麻烦？MySQL本身不行吗？"那一刻我意识到，这个需求已经不是"可以不可以"的问题了，而是"为什么还不行"。MySQL在9.5版本里直接内置了NL_SQL功能。你不需要装什么插件，直接用自然语言描述问题，它就能生成对应的SQL并执行。比如你问"找出过去三个季度复购率下降最多的五个品类"，它会先理解你的问题，查询相关的表结构，然后生成可执行的SQL，最后把结果返回给你。这意味着什么？意味着那些需要天天写简单查询的业务人员，终于可以不用学SQL了。而我们这些写了十年SQL的人，开始需要重新思考自己的不可替代性。微软在SQL Server 2025里塞进了完整的企业级AI能力：内置机器学习模型管理，可以调用Azure OpenAI、Azure Foundry的模型支持LangChain、Semantic Kernel这些主流框架简单说就是把AI能力做进了数据库内核，而不是外面套一层包装。这对于已经在用SQL Server的企业来说，迁移成本几乎为零。Azure SQL Managed Instance直接接入了Microsoft Copilot。你可以用自然语言问"过去一周查询性能为什么下降了"，Copilot会自动分析Query Store、DMVs、系统诊断数据，给出带上下文的诊断报告。DBAs不用再手动翻日志了。问一句"为什么慢"，它告诉你根因在哪、建议怎么改。这是DBA工作模式的根本转变——从手动排查到对话式诊断。以前我们说数据是资产，数据库是仓库。现在数据库厂商在告诉你：光存数据不够，我要在仓库里直接给你加工好。MySQL把自然语言理解做进去，SQL Server把向量检索做进去，Azure SQL把Copilot做进去。殊途同归。这背后的逻辑是：数据的流动性越低，AI处理的延迟和成本就越低。数据不动，让模型去找数据，而不是把数据搬到模型里。这个思路正在成为基础设施层的共识。自然语言SQL意味着什么？意味着"会写SQL"这件事的价值在重新定价。以后初级数据分析师的核心技能，可能不再是写SQL有多快，而是能不能用业务语言准确描述需求、能不能判断AI生成的SQL对不对、能不能验证结果合不合理。SQL会变成一种"底层协议"，大多数人不需要直接读写，但需要理解它在做什么。Cursor删库事件暴露了一个问题：AI代理的执行能力和安全约束之间的错位。当数据库本身开始内置AI能力，这个问题会更加尖锐。谁可以问什么问题？谁可以触发什么操作？AI生成的查询能不能自动执行？这不只是技术问题，也是权限模型和治理框架的问题。在这个领域，有能力设计安全边界的人，会变得很值钱。BI分析师的日常工作正在被重新定义。 以前你花两个小时写的月度报表，现在AI可以在十分钟内生成草稿，你来做审核和解读。这是效率提升，也是在倒逼你做更有判断力的工作。数据工程师的价值锚点在迁移。 当数据库本身可以处理向量、可以跑机器学习、可以用自然语言交互，ETL和SQL工程师的需求结构会变。懂数据架构、懂模型部署、懂AI治理的人会更稀缺。DBA的角色在进化。手动排查问题的场景会减少，但设计AI驱动的监控体系、制定数据访问策略、处理更复杂的安全合规问题，这些工作反而会更重要。如果业务团队提了一个需求：让业务人员可以直接用自然语言查询数据，不需要经过数据团队。传统方案是搭一套ChatBI，加个中间层（Skills，MCP等），对接各种数据源。做完可能效果会很一般，因为中间层和数据源之间的语义对齐很难维护，维护成本很高。新的思路是什么？让数据库自己具备AI能力，从源头解决语义对齐问题。MySQL AI、SQL Server 2025、Azure SQL MI都在朝这个方向走。这个方向上，缺的是能把AI能力和企业数据架构结合起来的人。你不需要是AI专家，但你要懂数据、懂业务、知道怎么设计让AI安全可靠地访问数据。
数据库AI化这件事，看起来是技术升级，本质上是数据工作模式的范式转移。以前我们说"数据驱动决策"，现在我们可能要说"AI驱动数据流动"。数据不只是被查询的对象，而是可以被理解、被推理、被主动加工的资产。
夜雨聆风