2026-11-11更新(以下の項目は無用)
lower_case_table_names = 0にすることで大文字も使えます。
ちなみにWinのDockerコンテナは0でした。(こちらの方がイレギュラーらしいが、wsl2のUbunts経由なのでそうなるらしい)
Macは2に設定されていました。(これが当たり前らしい)
https://dev.mysql.com/doc/refman/8.0/ja/identifier-case-sensitivity.html
考え方としてはDockerが実行される環境のファイルシステムに合わせる方が事故が少ないとのことらしいので、WinとMacでは大文字小文字を区別しないので1以上になるらしいです。
厳格な方がバグも早期発見でき事故も少ないと思うので「lower_case_table_names = 0」で運用することが良い気がしますね。
# MariaDB(MySQL)にログイン後、以下のコマンドで確認できます。
SHOW VARIABLES LIKE 'lower_case_table_names';
尚、Dockerだとホストのフォルダにマウントするとこの設定が禁則となり実施できない。
しつこい様だがWinはUbunts経由なので禁則とならない。
その場合、docker-compose.ymlには
services:
mariadb:
image: mariadb:10.11
command:
- --lower-case-table-names=0
volumes:
- mariadb_data:/var/lib/mysql
volumes:
mariadb_data:
とすることで、Named VolumeとなりDockerDesktop管理となってホストのファイルシステムには依存しなくなるが、元々DBファイルのマウントは編集作業はなくコンテナ再生成時のデータの維持が目的なので問題はないと思います。
これだけで9時間ほど使っちゃった・・・。
症状(MacのDockerのみ発症)
- テーブル作成後にインデックスを追加しようとすると1146エラー、そんなテーブルは存在しないと言われる。
- ちなみにLarvelのmigrationを実施した際におきました。
- 当該テーブルに対する2発目のmigrationファイルが実行後にテーブルが削除され、3発目のmigrationファイルが実行する際に1146エラーがスローされた。
顛末
1990年代に作成された、MSSQL7からの移植でそのDBでは大文字のテーブル名が使われていた。
話はそれますが、これも含めVB6とかほんと地獄です。
原因
- 対象はDockerなのでLinuxなのだが、Macの仕様が影響するようです。
- 大文字と小文字の区別に問題があるのは既知の事らしい。
- テーブル作成後にテーブルを司るファイルで大文字小文字が存在してしまう。
- frmファイルは大文字のテーブル名だがibdファイルは小文字のテーブル名になってしまう。
- ちなみにこのコンテナをWinでも生成しているが、この症状は出ない。
- WinもMacも大文字小文字のファイル名を区別しないOSではあるようなのですが・・・。
Macでしか発症しないからといってMacで開発をやめるとかは本末転倒です。
全てのテーブル名を小文字
きっとこの症状はMySQLでも発症すると思います。
対処(Laravel)
一からコンテナを再生成するのであればテーブル名を小文字に変更する以外は特に不要。
コンテナを継続して利用する場合
# bash
php artisan migrate:fresh # これは必須事項
# php laravel migration
public function up(): void
{
# 以下を最初に実行する必要がある、ゴミとなる情報を削除する
DB::statement('DROP TABLE IF EXISTS 大文字のテーブル名');
DB::statement('DROP TABLE IF EXISTS 小文字のテーブル名');
Schema::create('小文字のテーブル名', function (Blueprint $table) {
}
}
おまけ
実はカラム名も大文字なので小文字にしたほうが良いのか検討しましたが、カラム名はテーブル名ほど影響がないそうです。
今更ですが、カラム名まで小文字かとなるとそれに対する工数が大きすぎて費用対効果が悪すぎますね。
もし、同様の依頼を受けた方が設計前にこの記事を見ることを祈りたいですね。
