rdbmsTweetMySQL8.0における文字セットの変更:デフォルトの文字セットがlatin1からutf8mb4に変更されます。これらのシステム変数は次のような影響を受けます。character_set_serverおよびcharacter_set_databaseシステム変数のデフォルト値は、latin1からutf8mb4に変更。collation_serverおよびcollation_databaseシステム変数のデフォルト値は、latin1_swedish_ciからutf8mb4_0900_ai_ciに変更。MySQL8.0では、Unicode9までアップグレードされています、またutf8mb4(4byte)では絵文字を含む文字も処理する事が出来る為、バージョンアップと共に文字コードや照合順序を変更される事もあるかと思います。簡単ですが、手順を再確認して見ました。MySQL8.0にアップグレードする前に,mysqlsh8.xのアップグレード確認ユーティリティでチェックするのもお勧めです。文字セットも確認してくれます。状況に応じて使い分けて下さい。変換結果としては、問題無くテーブルのDefault文字セットはutf8mb4に変換されている。sec)但し、上記のようにテーブルのDefault文字セットを変換しただけの場合、以下の様にテーブルのカラムなどの文字コードは変換されていない。新しい文字セットに変更するには、次のようなステートメントを使用。collation_name];注意:このステートメントでは、すべての文字カラムの照合順序も変更されます。句を指定しない場合、このステートメントは、その文字セットのデフォルトの照合順序を使用します。場合は、照合順序を明示的に指定します。以下のテーブルは、文字セットと照合順序変更に伴いFK制約に引っかかってしまったので、マニュアルで対応する。sec)該当テーブルを変換後は問題無く、スクリプトでまとめて変更する事が出来た。sec)テーブルの文字コード変換スクリプト作成と実行、TABLEの照合順序がCity2だけutf8mb4_binのまま残っている。sec)一度、テーブルのcharacter_setを上記のステップでutf8mb4に変換しているのでここでは外して、テーブルと列の文字セット変換スクリプトを実行したが、FKのエラーになったので、FKを無効にして関連テーブルをマニュアルで変換しておく。※テーブルだけでは無く、列の文字セットや照合順序も変わるので大文字小文字の区別などが変わると困るテーブルなどは個別にマニュアル対応して下さい。sec)対象テーブルの制約は対応済みなので、問題無く変換が終了。全てのテーブルの文字コードも照合順序も適切に変換された事を確認。sec)変換後もutf8からutf8mb4への変換なので特にデータに問題は無い。絵文字もutf8mb4なので問題無くINSERT出来る事を確認。文字関連のデータ型に関しては、キャラクターセットも照合順序も問題無い事が確認出来る。sec)詳細:Collation変更にあたり、色々と考慮しなければいけない事がまとめられていて参考になります。https://mysqlserverteam.com/mysql-8-0-collations-migrating-from-older-collations/特定の文字セットを使用するように、バイナリ文字列または非バイナリ文字列カラムを変換する為の注意点が書いてあります。抜粋:正しく変換が行われるには、次の条件のいずれかを適用する必要があります。使用してエンコードされる必要があります。どの値がどの文字セットを使用するかを認識できず、データを正確に変換できません。ある場合、その内容は、カラムの文字セットでエンコードする必要があり、ほかの文字セットは使用できません。内容が別の文字セットでエンコードされている場合、最初にバイナリデータ型を使用するようにカラムを変換してから、使用する文字セットで非バイナリカラムに変換できます。データ値をマップしようとしますが、文字セットに互換性がない場合、データの損失が生じる可能性があります。SETを利用する場合の注意に関しては、此方も合わせて確認して下さい。MySQL8.0にした場合は特に指定しなければDefaultで基本的には問題無い設定が適用されるので、マニュアルで指定している場合やカスタマイズしている場合は確認して下さい。rdbmsTweetMySQL8.0のエラーログの設定オプションが変わっているので、Fredのブログを確認しながら検証環境で確認しました。新しいコンポーネントベースのエラーログには次の機能があり、自分の環境にあった設定を選択する事が可能になっています。ログイベントは、フィルタコンポーネントによってフィルタリングして、書き込みに使用できる情報に影響を与えることができます。(writer)コンポーネントによって出力されます。複数のシンクコンポーネントを有効にして、エラーログの出力を複数の宛先に書き込むことができます。フィルタとライターの組み込みコンポーネントが組み合わされて、デフォルトのエラーログフォーマットが実装されています。ロード可能なライターを使用すると、システムログにロギングできます。ロード可能なライターを使用すると、JSON形式でのログ記録が可能になります。システム変数は、有効にするログコンポーネントとログイベントをフィルタリングするルールを制御します。log_error_servicesシステム変数は、エラーログに有効にするログコンポーネントを制御します。その値は、セミコロンで区切られたコンポーネントのリストです。スペースは重要ではありませんが、リストされた順序でコンポーネントを実行するため、コンポーネントの順序は重要です。JSONフォーマットのログを利用したいので、JSON用のコンポーネントを追加しています。メモ:log_errorがstderrの場合、JSONライターはコンソールにログを書き込みます。sec)MySQLを再起動して、JSONフォーマットのエラーログが追加されているか確認。log_sink_internalとlog_sink_jsonの2つが順に列挙されている為、エラーログは通常のエラーとJSONフォーマットのエラーログの2つが出力されています。以下、マニュアル抜粋log_filter_internal:優先度に基づくエラーログのフィルタリングエラーログの冗長性制御は、エラーイベントの優先度に基づいたログフィルタリングの簡単な形式です。これは、log_filter_internalログフィルタコンポーネントによって実装されます。log_filter_internalがエラー・ログを対象とするエラー、警告、およびメモイベントを許可または抑制する方法に影響を与えるには、log_error_verbosityシステム変数を設定します。log_filter_internalはデフォルトで組み込まれ、有効になっていますが、無効にするとlog_error_verbosityの変更は無効です。許可されるlog_error_verbosityの値は、1(エラーのみ)、2(エラーと警告)、3(エラー、警告、およびメモ)log_filter_dragnet:ルールベースのエラーログのフィルタリングlog_filter_dragnetログフィルタコンポーネントは、ユーザ定義のルールに基づいてログフィルタリングを有効にします。適用可能なルールを定義するにはdragnet.log_error_filter_rulesシステム変数を設定します。詳細:https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_dragnet.log_error_filter_ruleslog_filter_dragnetフィルタを有効にするには、まずフィルタコンポーネントをロードしてから、log_error_services値を変更します。log_filter_internal:優先度に基づくエラーログのフィルタリングエラーログの冗長性制御は、エラーイベントの優先度に基づいたログフィルタリングの簡単な形式です。これは、log_filter_internalログフィルタコンポーネントによって実装されます。log_filter_internalがエラー・ログを対象とするエラー、警告、およびメモイベントを許可または抑制する方法に影響を与えるには、log_error_verbosityシステム変数を設定します。log_filter_internalはデフォルトで組み込まれ、有効になっていますが、無効にするとlog_error_verbosityの変更は無効です。log_sink_internal、log_sink_test:これらのライターは、file_nameに書き込みますlog_sink_json:log_error_services値で指定されたこのライターの連続インスタンスは、file_nameという名前のファイルと、番号付きの.NN.json接尾辞:file_name.00.json、file_name.01.jsonなどに書き込みます。詳細:https://dev.mysql.com/doc/refman/8.0/en/error-log-json.htmllog_sink_syseventlog:このライターは、log_error値に関係なく、システムログに書き込みます。log_sink_internal、log_sink_json、log_sink_test:これらのライターはコンソールに書き込みます。rdbmsTweetSYSスキーマの説明をする機会があったので、改めてMySQL5.7.21でSYSスキーマに関しての概要をまとめたのでご紹介。Information_Schemaを直接確認しないと取得出来無い情報もまだあるけれど、SYSスキーマを利用すれば簡単にMySQLの状態を確認出来、複雑なクエリーを使わないでもロックの状態、メモリーの状態、未使用のインデックス、起動してからの累積値だけれども遅いクエリー等が確認可能です。使われていないユーザーも多いけど、便利なので是非活用下さい。MySQL5.7.21の時点では以下のオブジェクトが存在します。sec)以下のスライドにまとめたので、詳細をご確認下さい。rdbmsTweetMySQLでGeoHashを試してみた。APIを利用して、住所から緯度経度を逆引きしてvarcharで作った列に情報を格納していましたが、あの時にgeohashを知っていたら色々とサービスで使えたかもしれない。思い、少し確認してみた。01111左から数え始め、経度は偶数ビット(1110001101011)、緯度は奇数ビット(101100101011)として表現される。二進数は1ビットずつ、左のビットから順に評価されるて、緯度については、-90から+90が2つの区間に分割され、経度は-180から+180の区間に分割される。sec)MySQL8.0のgeohash関連関数ST_から始まるものが、最新のGEO関数です。ST_GeoHash(経度,緯度,最大長)、ST_GeoHash(point,max_length)接続文字セットと照合順序でgeohash文字列を返します。ST_LatFromGeoHash(geohash_str)geohash文字列値から[-90、90]の範囲の倍精度数として緯度を返します。ST_LongFromGeoHash(geohash_str)geohash文字列値から[-180,180]の範囲の倍精度数値として経度を返します。ST_PointFromGeoHash(geohash_str、srid)geohash文字列値を指定して、解読されたgeohash値を含むPOINT値を返します。Mapを利用して確認オラクル青山オフィスのgeohash(5桁:xn76g)を利用してレストランを検索。データをImport後に、緯度-経度を読み込んで確認してみる。検証用のデータはこちらからダウンロード可能です。region:Asiahttp://download.geofabrik.de/asia.htmlインポート方法はこちらが参考になります。APIに渡して、地図を確認してみると、問題なく、同じGeohashにあるレストランが表示されているようです。インデックスを併用すれば、結構レスポンスの良い空間データベースになりそうです。上記処理を実行した時の、MySQLで実行プランは以下のような感じです以上で確認は終了ですが、ついでにSRIDを指定してテーブルを作成する事が出来るようになっていたので確認してみた。緯度-経度の順番でINSERTする場合は、列にSRIDを指定して作成した方が良いようです。反対に経度-緯度の場合はDefaultの0のままで良い。データINSERT時に緯度と経度の順番のバリデーションが無いのであった方がよさそうです。