窗外是上海漕河泾软件园傍晚特有的那种嘈杂，刚下班的程序员们三三两两走过，空气里飘着廉价咖啡和焦虑混合的味道。我盯着屏幕上那个慢得令人发指的查询语句，已经三个小时了。一个看似简单的用户行为筛选，当数据量爬到百万级，响应时间就从毫秒变成了分钟。后端同事扔过来一句冷冰冰的：“PM 能不能别老提这种‘全表扫描’式的需求？” 我32岁了，自诩懂点技术，可那一刻，脸上火辣辣的。
不懂。是真的不懂。我满脑子都是流量、转化、闭环，张口闭口“大数据赋能”，可当研发把执行计划拍在我面前，那些“全表扫描”、“回表查询”、“索引失效”的术语像一记记闷棍。我忽然意识到，过去那些被我轻飘飘写进 PRD 的“支持多维度、实时、海量数据筛选”，背后可能是一个个技术深渊。所谓的“大数据”，如果连最基础的“数据怎么被快速找到”都搞不明白，一切酷炫的概念都是空中楼阁。那种感觉，就像你指挥一场战役，却连子弹是怎么从枪膛里射出去的都不知道。
不行，得啃下来。从那天起，我像个偏执的独狼，开始死磕。白天跑需求、对方案，晚上就扎进那些枯燥的底层资料里。我找来了《高性能 MySQL》，把电子版塞进手机，通勤的地铁上、排队买咖啡的间隙，都在看。一开始简直是天书，B+树、聚簇索引、覆盖索引、最左前缀原则……每个词都认识，连起来就让人头晕。我试着在本地数据库里复现问题，建表，灌入几百万条模拟数据，然后疯狂地写查询、加索引、看执行计划。
最折磨人的是那种“似懂非懂”的状态。你知道索引能加速，但为什么加了索引反而更慢？你知道联合索引有用，但字段顺序该怎么定？有一次，我为了优化一个复杂的多条件联合查询，设计了五六个索引方案，一个个测试。其中一个方案，在测试环境小数据量下快得飞起，我差点就要欢呼了，结果压测数据一上来，瞬间崩盘。原因是索引选择性太差，导致查询优化器错误地选择了它，引发了大量的随机 I/O。那个晚上，我对着满屏的监控曲线和错误的执行计划，第一次对“成本”这两个字有了血肉般的感知。数据库的“成本”不是钱，是 CPU 周期，是磁盘 I/O 次数，是内存占用。每一个轻率的查询，都在消耗实实在在的硬件资源，而这一切，最终都会转化成研发的加班、服务器的账单和用户流失的等待时间。
我慢慢开始用这种“成本思维”去反推产品设计。再也不会提“把所有用户标签都拿来实时交叉分析”这种蠢需求了。我会先问：核心的查询场景是什么？数据更新的频率有多高？可以接受多长时间的延迟？如果非要实时，那么数据量和筛选维度能不能做减法？能不能用预计算、用缓存、用异步队列来换时间？我开始在需求评审会上，用研发能听懂的语言讨论技术方案，甚至能指出某些表设计可能存在的性能隐患。那种感觉，不是炫耀，而是一种终于从“外行指挥内行”的羞愧中挣脱出来的踏实感。
但焦虑从未消失，它只是换了一种形式。以前是焦虑自己不懂，现在是焦虑要学的东西太多，而且越来越深。数据库只是底层存储，上面还有缓存、消息队列、分布式计算……每一个环节不理解，都可能让整个系统崩掉。有时候深夜对着电脑，会突然觉得很累。学这些到底为了什么？就为了在评审会上不被研发怼吗？
不。是为了不让那些熬夜敲代码的兄弟，因为我的无知而白费功夫。是为了我画出的每一个原型、写下的每一行需求，最终都能高效、稳定地跑在服务器上，而不是成为技术债。是为了当我说“我们要做大数据分析”时，心里清楚它的代价和边界在哪里。
理解索引，或许只是万里长征的第一步。但这一步让我明白，产品经理的技术能力，不是为了替代工程师，而是为了在商业价值和技术实现之间，搭建一座不至于坍塌的桥梁。这座桥，得用对技术的敬畏，和死磕细节的偏执，一砖一瓦地垒起来。
窗外的嘈杂早已散去，只剩屏幕的光映在脸上。我关掉数据库客户端，在需求文档的备注栏里，加了一行小字：“此筛选条件需结合用户 ID 前缀及时间范围，建议使用复合索引 (user_id_prefix, action_time)，并注意避免索引失效写法。” 这大概是一个产品经理，能写给研发的，最朴素的情书了。
