title: What are the consequences if character sets for Triggers and Views do not match rest of database?
body: <p>We've recently gone through the effort of converting all our application's MySQL tables, columns, and .ini settings to utf8 encoding. However, we've found that <strong>views</strong> and <strong>triggers</strong> created prior to this change still have a reference to the latin1 character set--i.e. the following queries return records:</p>
  
  <pre><code>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')
  ;
  </code></pre>
  
  <p><strong>Do I need to be concerned about this?</strong></p>
  
  <p>The MySQL documentation on <a href="https://dev.mysql.com/doc/refman/5.6/en/triggers-table.html">information_schema.triggers</a> and <a href="https://dev.mysql.com/doc/refman/5.6/en/views-table.html">information_schema.views</a> only says "The session value of the character_set_client system variable when the trigger was created." If that's all the value is storing, then is there any reason to try to fix them? (It doesn't sound like that would matter.) But on the other hand, I have to think the database developers chose to store it in the information_schema tables for <em>some</em> reason.</p>
  
  <p>Production has been on utf8 for a while with the views and triggers still referencing latin1, and we haven't seen any issues (although we don't have a very large non-English user base). I've done some testing with different test strings and haven't seen any character corruption.</p>