MySQL大表（700k行）索引与business_codes工具开发技术咨询
Hey Jack, let's break this down step by step since you're stuck on where to start with that business_codes column tool. First off, 700k rows isn't huge but with all those indexes and text-heavy data, we need to be careful not to tank performance. Here are some actionable tips to get you going:
先锁定核心需求：You didn't get into the details of what's in
business_codes(comma-separated values? JSON arrays? free-form text?), but start by pinning down exactly what your tool needs to do. Is it extracting rows with specific codes? Bulk updating old codes to new ones? Generating reports on code frequency? Nailing this down will immediately narrow your focus instead of staring at a blank canvas.核查列的存储格式：
- 如果是分隔符字符串（比如
"RETAIL,FOOD,SERVICE"），别用偷懒的LIKE '%RETAIL%'查询——它会无视你建的所有索引，触发全表扫描。换个思路：- 用数据库内置函数拆分代码，生成临时关联表。比如PostgreSQL用
unnest(string_to_array(business_codes, ','))，MySQL用JSON_TABLE，SQL Server用STRING_SPLIT。给临时表加个索引，后续操作速度会提升一大截。 - 如果这个工具是长期需求，考虑重构为多对多关联表，替代单文本列存多个代码的方式。虽然要改表结构，但能彻底解决文本查询的性能痛点——这对你需要多方式对接数据的网站来说特别关键。
- 用数据库内置函数拆分代码，生成临时关联表。比如PostgreSQL用
- 如果是JSON格式，一定要用数据库原生的JSON函数和索引。比如PostgreSQL的
jsonb列配GIN索引，能让数组查询快到飞起。别把JSON转成文本查询，用jsonb_array_elements这类原生函数来处理数据。
- 如果是分隔符字符串（比如
用好现有索引，但别盲目依赖：
- 先查一下
business_codes列有没有已建的索引。标准B-tree索引对模糊文本匹配没用，但全文索引或部分索引（针对常用代码前缀）会很有用。 - 执行任何大查询前，先跑
EXPLAIN看执行计划。这能帮你排查是否触发了全表扫描，700k行的表如果全扫，速度会慢到离谱。
- 先查一下
小范围测试后再扩量：
- 别一开始就直接处理全表。先抽1000行数据测试工具逻辑，验证输出是否正确，看看执行时间和资源占用（CPU、内存、磁盘IO）。把小样本里的问题都解决了，再逐步扩大到全数据集。
能离线处理就别碰线上：
- 如果工具不需要实时运行（比如批量更新、数据导出），就安排在低峰时段执行。或者把相关数据导出到测试环境，在那里跑完工具再同步结果回去。这样不会锁表，也不会拖慢线上网站的数据对接速度。
内容的提问来源于stack exchange，提问作者Jack Hammerly
