我们最近已经完成了将所有应用程序的MySQL表,列和.ini设置转换为utf8编码的工作.但是,我们发现在此更改之前创建的视图和触发器仍然引用了latin1字符集 - 即以下查询返回记录:
SELECT * FROM information_schema.triggers
WHERE trigger_schema=SCHEMA()
AND (collation_connection != 'utf8_general_ci' OR character_set_client != 'utf8')
;
SELECT * FROM information_schema.views
WHERE table_schema=SCHEMA()
AND (collation_connection != 'utf8_general_ci' OR character_set_client != 'utf8')
;
Run Code Online (Sandbox Code Playgroud)
我需要关注这件事吗?
有关information_schema.triggers和information_schema.views的MySQL文档仅显示"创建触发器时character_set_client系统变量的会话值".如果这就是存储的全部价值,那么有没有理由尝试修复它们?(听起来并不重要.)但另一方面,我必须认为数据库开发人员出于某种原因选择将其存储在information_schema表中.
生产已经在utf8上进行了一段时间,视图和触发器仍然引用了latin1,我们没有看到任何问题(尽管我们没有非常大的非英语用户群).我已经使用不同的测试字符串进行了一些测试,并且没有看到任何字符损坏.
请参阅下面引文中的粗体文本.如果您non-ASCII在触发器/视图中使用了字符,例如与您的某个UTF-8列进行比较,则最好重新创建它们.如果不是,则无关紧要,因为这些变量用于设置稍后使用/重新创建对象的上下文.
从MySQL 5.1.21(2007-08-16)的变化引用
错误修复
不兼容的更改:为存储的程序(存储过程和函数,触发器和事件)以及包含非ASCII符号的视图确定了几个问题.这些问题涉及在将这些对象与存储格式进行转换时由于字符集信息不完整而导致的转换错误,例如:
解析原始对象定义以便可以存储它.
在调用对象时将存储的定义编译为可执行的形式.
从INFORMATION_SCHEMA表中检索对象定义.
在SHOW语句中显示对象定义.这个问题也影响了使用SHOW的mysqldump.
问题的解决方法是存储来自对象创建上下文的字符集信息,以便在以后需要使用该对象时可以使用此信息.上下文包括客户端字符集,连接字符集和排序规则,以及与对象关联的数据库的排序规则.
作为补丁的结果,几个表有新列:
在mysql数据库中,proc和event表现在具有以下列:character_set_client,collation_connection,db_collation,body_utf8.
在INFORMATION_SCHEMA中,VIEWS表现在具有以下列:CHARACTER_SET_CLIENT,COLLATION_CONNECTION.ROUTINES,TRIGGERS和EVENTS表现在包含以下列:CHARACTER_SET_CLIENT,COLLATION_CONNECTION,DATABASE_COLLATION.
这些列存储character_set_client和collation_connection系统变量的会话值,以及与该对象关联的数据库的排序规则.值是在对象创建时生效的值.(保存的数据库排序规则不是collation_database系统变量的值,它适用于默认数据库;包含该对象的数据库不一定是默认数据库.)