不同字符集MySQL表的查询改写与字符集变更风险咨询

问题1：修改表字符集是否会导致数据异常？该操作是否安全？ #

修改表字符集的安全性与数据异常风险，完全取决于目标字符集与原字符集的兼容性，以及现有数据的内容：

两种转换场景的风险分析 #

• 将razorpay_enach_consent（utf8mb4）转为latin1：
  utf8mb4支持全Unicode字符（包括emoji、生僻汉字等），而latin1仅支持西欧字符集。如果原表中存在latin1无法编码的字符，转换后这些字符会被替换为?，造成永久数据损坏，风险极高，不建议操作。
• 将loan_schedules（latin1）转为utf8mb4：
  latin1的所有字符都属于utf8mb4的子集，转换过程不会丢失数据，是安全的。但需注意：
  • 仅修改表的字符集不够，需同步修改表中所有字符类型列的字符集（表级字符集仅为新列提供默认值）；
  • 转换后建议重建表的索引，避免因字符集变更导致索引失效或性能下降；
  • 操作前务必备份数据，在测试环境验证后，选择业务低峰期执行（InnoDB的ALTER TABLE虽为在线DDL，但仍会有短暂锁表影响）。

问题2：使用CONVERT USING latin1改写SQL查询 #

原查询中两个表通过loan_id关联，但字符集不同，可能触发隐式字符集转换，存在性能隐患。我们需要将razorpay_enach_consent的loan_id转换为latin1，与loan_schedules的字符集一致，确保关联时能正常使用索引：

改写后的SQL #

select 
  adc.consent_id, 
  adc.user_id, 
  adc.loan_id, 
  ls.loan_schedule_id, 
  adc.max_amount, 
  adc.method, 
  ls.due_date, 
  DATEDIFF(CURDATE(), ls.due_date), 
  l.status_code 
from 
  razorpay_enach_consent as adc 
  join loan_schedules as ls on CONVERT(adc.loan_id USING latin1) = ls.loan_id 
  AND adc.is_active = 1 
  AND adc.token_status = 'confirmed' 
  and ls.due_date <= DATE_ADD(now(), INTERVAL 1 DAY) 
  and ls.status_code = 'repayment_pending' 
  and ls.due_date >= date_sub(now(), INTERVAL 2 day) 
  and ls.loan_schedule_id not in (
    select 
      loan_schedule_id 
    from 
      repayment_transactions rt 
    where 
      rt.status_code in (
        'repayment_auto_debit_order_created', 
        'repayment_auto_debit_request_sent', 
        'repayment_transaction_inprogress'
      ) 
      and rt.entry_type = 'AUTODEBIT_RP'
  ) 
  join loans l on adc.loan_id = l.loan_id 
  and l.status_code = 'disbursal_completed' 
limit 
  30

说明 #

• 核心修改点：将关联条件adc.loan_id = ls.loan_id改为CONVERT(adc.loan_id USING latin1) = ls.loan_id，强制统一字符集；
• 补充了原查询中遗漏的ls.前缀（ls.due_date >= date_sub(now(), INTERVAL 2 day)），避免字段歧义；
• 该改写可确保loan_schedules的fk_loan_schedules_loans索引正常被使用，维持原执行计划的性能。

内容的提问来源于stack exchange，提问作者RRQ