SQLの2003や2013というエラーを回避しつつ，4GB以上のデータベースを管理したい

Question

前提・実現したいこと

はじめまして．
MySQLを利用して1年分のデータを読み込んでSQL上で管理したいです．
このデータは2016年6月分だけで2.7GBあり，2016年7月分をPythonを用いて同様に追加で読み込んだ際に4GBを超えるためエラーが出ました．
なお，データはHDDに保存したCSVファイル（例：E:/1-2/OUT1-2_20160601/data.csv）であり，6月1日，2日…30日と1日分で1ファイルとなっています．
Python上では以下のようなプログラムで読み込みを行いました．

conn = MySQLdb.connect(
    db="database_spd",
    user="root",
    passwd='root',
    host='localhost',
    local_infile=True,
    charset="utf8"
)

# カーソルを作る
#月によって日数が違うことに注意（28から31の間：特にうるう年に注意）
cursor = conn.cursor()
days = ['01','02','03','04','05','06','07','08','09','10',
'11','12','13','14','15','16','17','18','19','20',
'21','22','23','24','25','26','27','28','29','30','31']
#SQL読み込み
for i in days:
    sql = '''
    use database_spd;
    select @@sql_mode;
    set autocommit=0;
    start transaction;
    load data infile 'E:/1-2/OUT1-2_201606''' + i + '''/data.csv' into table data_1_2
    fields
     terminated by ','
     enclosed by '"'
    lines
     terminated by '\r\n'
     ( data_a, data_b, data_c, data_d, data_e, @data_v, @height, data_f, @data_1, @data_2,
    @ver, data_g, @in, @out, @distance, data_h, @no, @direction, @whois, data_i   )
    set
     data_v = case @data_v when '' then null else @data_v end,
     height = case @height when '' then Null else @height end,
     data_1 = case @data_1 when '' then Null else @data_1 end,
     data_2 = case @data_2 when '' then Null else @data_2 end,
     ver = case @ver when '' then Null else @ver end,
     in = case @in when '' then Null else @in end,
     out = case @out when '' then Null else @out end,
     distance = case @distance when '' then Null else @distance end,
     no = case @no when '' then Null else @no end,
     direction = case @direction when '' then Null else @direction end,
     whois = case @whois when '' then Null else @whois end;
    '''
    cursor.execute(sql)


users = cursor.fetchall()
for user in users:
    print(user)

cursor.close()
conn.commit()# コミットし、更新を反映->こないとDBにデータ流れない
conn.close() # 接続解除

そこでデータの制限を緩めるべくMySQL上で設定を行ったのですが，その設定がよくなかったためか

Error Code: 2013. Lost connection to MySQL server during query

というエラーや

Error Code: 2003 Unable to connect to localhost

というエラーが出て，MySQLをMAMPでボタンを押して起動させてもすぐサーバーが落ちるようになってしまいました．

データの詳細

この際，2018年6月分のデータ概要は以下のようになっています．
![

また，現在使用中の環境では

select @@global.myisam_data_pointer_size;

と入力した場合

+-----------------------------------+
| @@global.myisam_data_pointer_size |
+-----------------------------------+
|                                 6 |
+-----------------------------------+

と返ってきます．そのため，256TBまでは問題ないはずです．

データの制限を緩めるためにやったこと

これが（おそらく）裏目に出ましたが，ここに記載します．

MySQLの公式マニュアルを参考にして，以下のようにテーブル制限値を余裕のある値にしました．

ALTER TABLE database_spd.data20_1_2 MAX_ROWS=1000000000000, AVG_ROW_LENGTH=400;

これを打ち込んでから最初の方に書いた2003や2013といったエラーが出るようになったのですが，
SQLのデータベース接続に影響を与えず，なおかつ4GB以上のデータを1つのデータベースファイルで管理する方法はあるのでしょうか．
ご回答よろしくお願いいたします．

補足情報（FW/ツールのバージョンなど）

環境：
Windows 10 Pro 64bit
MAMPによるMySQLインストール
MySQL Workbench使用

Comments

[m.ts10806]

WindowsにMAMPという時点で適性から外れるように思いますが（一般的にはXAMPP。でもPHP使わないなら無用の長物）
それよりも「なぜMySQLを採用するのか」という点ではないでしょうか。
確かにその容量はどこかで持つことになるとは思うのですが、
そもそもそのデータがどのように作られ、どのように使われるのか
本当に全ての項目が必要なのか、とか
情報の整理が必要に思います。あまり現実的な容量ではないですし

[sazi]

> 4GBを超えるためエラーが出ました．
これはphyton側の処理でのエラーなのでは？
MySQLがデフォルトでも、その程度の容量でエラーにはならないと思いますし。

[fujicho_100]

ご回答ありがとうございます．

まず，MAMPをインストールした理由は参考にしている書籍の　西沢夢路：「基礎からのMySQL第3版」（SBクリエイティブ，2017）に紹介してあり，参考にしたためです．
観測された回数が大量にあり，その度ににデータがとられているため，Excelでとても計算・抽出できる行数ではないためにMySQLを使用しています．

また，Python側のエラーというのは考えていなかったことでした．これが解決しない場合，月（2016年6月，2016年7月…）ごとにテーブルを作って整理することも考えています．

[fujicho_100]

また追記ですが，2003や2013といったエラーを解決しなくては月ごとにテーブルを作って読み込むことも難しい八方塞がりの状態なので，そのあたりももし可能でしたらご回答いただけるとありがたいです．

[sazi]

MySQLにはLOAD DATA INFILEというCSVをインポートするコマンドがありますよ。
https://dev.mysql.com/doc/refman/5.6/ja/load-data.html
> 2003や2013といったエラーを解決
設定を元に戻す事です。

[fujicho_100]

>saziさん

ありがとうございます．当初はこのコマンドを使っていたのですが，一度に1か月分を読み込みたかったのでPythonを使いました．もしSQLだけでできるようでしたら，また後程調べてみます．

[fujicho_100]

>saziさん
また，
ALTER TABLE database_spd.data_1_2 MAX_ROWS=1000000000000, AVG_ROW_LENGTH=400;
と入力して，設定を変えてしまったことが原因だと思うのですが，
この初期値が分からず元に戻せない状況です．

[sazi]

mysqlimport であれば複数ファイルに対応しています
https://dev.mysql.com/doc/refman/5.6/ja/mysqlimport.html

[fujicho_100]

>saziさん
ありがとうございます．今はそもそもSQLが一切動かせない状況になっているため，アンインストールして再インストール後に試してみようかと考えています．
※設定を戻すこともできません

[sazi]

そうですね。クリーンインストールしてから再開するのが良いでしょう。

元々と言えば、ファイルごとにテーブルが必要だと誤解している所から始まっているようですので。

[fujicho_100]

>元々と言えば、ファイルごとにテーブルが必要だと誤解している所から始まっているようですので。

ここでの「ファイル」とは上記の質問で言えば2.7GBのもの（.ibd形式）を指しますでしょうか？
複数のファイルに分割したテーブルも可能ということで間違いないでしょうか．

[sazi]

質問ではCSVとなっていますが、.ibdファイルを使うのですか？
CSVがどの時点で分割されているのか分かりませんが、複数のファイルであってもそれぞれ追加すれば良いだけですけど。

[fujicho_100]

>質問ではCSVとなっていますが、.ibdファイルを使うのですか？

もともとのデータがCSVで，それをPythonを使ってSQLにインポートしている，という意味です．

[m.ts10806]

＞「基礎からのMySQL第3版」（SBクリエイティブ，2017）に紹介してあり，参考にしたためです．

OSがMac前提ではないでしょうか。
もしOS限らずMAMPすすめてるとしたら書籍としては信用できません（そもそも4年前は古い）

[fujicho_100]

>もしOS限らずMAMPすすめてるとしたら書籍としては信用できません（そもそも4年前は古い）

WIndows10前提でした．4年前でも古いというのは意外ですが，かなりアップデート等は頻繁に行われているのでしょうか．

[m.ts10806]

>WIndows10前提でした
「捨ててください」と言う人もいるレベルです。
teratailの質問見ればわかりますがWindowsにMAMPで詰まって質問してきてXAMPPに切り替えて前に進んだという人が何人も。

＞4年前でも古いというのは意外ですが，
日進月歩の世界において１年でも古いです。
MAMPの話が出ているのでPHPベースで話しますと、
2017年にはPHP7.2が出ましたが、もう8が出てます。
他の言語やフレームワークもどんどんアップデートしてます。
MySQLも8が出てます。
マイナーバージョンアップレベルでも仕様が変わったりするので
なるべく最新を取り扱っている資料は必須です。
本よりドキュメント見るのが確実です。

[fujicho_100]

>「捨ててください」と言う人もいるレベルです。
一応対応している，というだけで適切とは言えないのですね．XAMPPを入れて，再インストールしたところ，MAMPに比べて重いですが動かせました．

>日進月歩の世界において１年でも古いです。
MySQLを使いだしたのが今年の4月なので，それ以前のことは分かりませんがそのように進化しているのですね．

>本よりドキュメント見るのが確実です。
Web上のドキュメントだと体系的にまとめられていないため分かりにくく感じますが，慣れるしかないですね…

[退会済みユーザー]

とりあえずMAMPはWindows版もあるので、頭ごなしにダメという必要はありませんが、mysqld.exeが32bitなので4GBの制限があります。
https://dev.mysql.com/doc/mysql-reslimits-excerpt/8.0/en/windows-restrictions.html
今回の要件ではNGですね。
最近のxamppのmysqld.exeは64bitなので、4GBの制限はありません。

インポートにかかる時間はチューニングで多少は落ち着くと思います。
またテーブルを分けずとも、月単位でコミットかけるだけで負荷は減りそうな気がします。
あとload data直後のfetchはなんなのかよく分かりません。

[fujicho_100]

>32bitなので4GBの制限があります。

そうなんですね．XAMPPにしたら問題ありませんでした．また軽量化に関しても今後検討します．

Answer 1

XAMPPによる再インストールの実施
6月，7月…と月ごとにテーブルを作ることによる4GB制限の回避

ただ，MAMPよりもXAMPPの方がデータのインポートに時間がかかる傾向（約4倍）にあることが難点に感じています．