在MySQL中，进行表结构的批量更新（如添加字段或索引）时，元数据锁（metadata locks, MDL）可能会导致其他正在运行的业务被阻塞，尤其是在高并发生产环境中。这是因为 MySQL 会在更改表结构时锁住相关的元数据，而此时其他事务如果试图访问同一个表，可能会被阻塞直到表结构更新完成。

为了防止元数据锁导致的业务阻塞，可以采取以下几种策略：

1. 使用pt-online-schema-change工具（Percona Toolkit）
   Percona Toolkit 提供了 pt-online-schema-change 工具，可以在线非阻塞地修改表结构，包括添加字段、索引等操作。这个工具的原理是通过创建一个临时副本表，逐步将数据从原表迁移到副本表中，从而避免直接修改表结构时锁住表的数据。

优点：
完全避免了元数据锁。
可以在表结构更改时，仍然允许正常的读写操作。
支持并发事务，修改操作会在后台进行。
使用方法：
pt-online-schema-change --alter “ADD COLUMN new_column INT” --execute --host= --user= --password= --database= --table=

该工具会在后台完成表结构的修改，不会阻塞业务操作。

2. 使用 gh-ost 工具（GitHub的在线表结构迁移工具）
   gh-ost 是另一种在线修改表结构的工具，由 GitHub 提供。类似于 pt-online-schema-change，gh-ost 也通过创建一个新的副本表来进行结构变更，并且通过迁移数据来逐步更新表，不会直接锁住表。

优点：
适用于高并发、大数据量环境。
支持在线迁移，避免阻塞。
可以在不锁表的情况下应用更改。
使用方法：
gh-ost --alter=“ADD COLUMN new_column INT” --host= --user= --password= --database= --table=

--approve-renaming
3. 在低峰时段进行表结构修改
如果无法使用 pt-online-schema-change 或 gh-ost，可以考虑在业务的低峰时段进行表结构的修改操作。这通常需要提前规划，确保不会影响到重要业务。

计划业务低峰期，如夜间或系统负载较低的时段，进行修改操作。
在此期间，可以暂停部分不关键的任务或减少并发，降低元数据锁争用的风险。
4. 通过锁粒度控制减少元数据锁的时间
如果在应用字段或索引时无法使用在线工具（如 pt-online-schema-change），可以考虑调整 DDL 操作的锁粒度，特别是在 MySQL 5.6 及以上版本中，MySQL 提供了 LOCK=NONE 的选项，这样可以尽量避免表级锁定。

在 MySQL 5.6 及以上版本中，ALTER TABLE 支持在线添加索引（ONLINE）和无需锁表的操作，尽量选择支持 ONLINE 操作的场景。

示例：添加索引时使用 ONLINE：
ALTER TABLE your_table ADD INDEX idx_column_name (column_name) ALGORITHM=INPLACE, LOCK=NONE;
这种方式可以减少表的锁定时间，尽量避免元数据锁对业务的影响。

5. 增加事务隔离级别
   在某些情况下，通过增加事务隔离级别（如使用 READ COMMITTED 或 READ UNCOMMITTED）来减少锁定争用和元数据锁的影响。但这种方法需要慎用，可能会导致脏读等问题，建议仅在不影响数据一致性的情况下使用。

6. 使用分区表
   如果表的大小和数据量非常大，可以考虑将表分区，通过分区表进行数据操作和结构变更。对分区表的操作（尤其是添加字段和索引）通常比操作非分区表更加平滑。

对分区表进行表结构修改时，通常不会对整个表加锁，而只会对特定的分区加锁，减少对业务的影响。
7. 提前进行性能测试和负载测试
在正式生产环境中进行批量更新表结构之前，进行压力测试和负载测试，尤其是在数据库负载较高时，测试表结构更新操作对数据库性能和业务影响的程度。这可以帮助你提前识别潜在的锁竞争和性能瓶颈。

总结：
为了避免 MySQL 中的元数据锁导致生产业务被阻塞，最佳的策略是使用在线迁移工具（如 pt-online-schema-change 或 gh-ost），这些工具可以在不锁表的情况下进行表结构更新，保证业务持续运行。若无法使用这些工具，计划在低峰时段进行修改，并考虑使用更精细的锁策略来减少业务中断时间。