MySQLで大量のダミーデータをテスト用に必要だったため、WEBをググって情報を集めてみました。 SQLだけで実現しているので使いやすいかと思います。 ##データ型別のランダムデータ作成方法 INT(1〜100の範囲)
![MySQLで簡単にランダムなテストデータを作成する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/81c889f4fd74c22fab721d0e211d5f63862f4140/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9TXlTUUwlRTMlODElQTclRTclQjAlQTElRTUlOEQlOTglRTMlODElQUIlRTMlODMlQTklRTMlODMlQjMlRTMlODMlODAlRTMlODMlQTAlRTMlODElQUElRTMlODMlODYlRTMlODIlQjklRTMlODMlODglRTMlODMlODclRTMlODMlQkMlRTMlODIlQkYlRTMlODIlOTIlRTQlQkQlOUMlRTYlODglOTAlRTMlODElOTklRTMlODIlOEIlRTYlOTYlQjklRTYlQjMlOTUmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWFmZGE2OWQ4N2ZjNDM5NzRlOWE3N2Y1ZmJmMzMxOTU2%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0YXlhc3UmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTMxZGU0OWQzMmFkZTE0NzdhMTU1NDE1ODk0YTFlZGQ4%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44K744Oz44K344Oz44Ot44Oc44OG44Kj44Kv44K5%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3De05484c2e03d3112b4919cf239ed8e25)
SELECT TABLE_SCHEMA, round( sum( DATA_LENGTH ) / ( 1024 * 1024 ) , 2 ) AS DATA_SIZE, round( sum( INDEX_LENGTH ) / ( 1024 * 1024 ) , 2 ) AS INDEX_SIZE, round( round( sum( DATA_LENGTH ) + sum( INDEX_LENGTH ) ) / ( 1024 *1024 ) , 2 ) AS TOTAL_SIZE FROM information_schema.TABLES GROUP BY TABLE_SCHEMA ORDER BY TOTAL_SIZE DESC;
Golangが一番パフォーマンスが良いかと予想していましたが、全く逆の結果になってしまいました。 Golangが遅い理由 遅い原因をいくつか考えて改善できないか試してみました。詳細は省きますが、以下の点については問題なさそうでした。 goroutineはリクエスト単位で起動している コネクションプールは有効になっている BeegoのORM特有の処理は主原因ではない(標準ライブラリのsql関数と大差なし) DB側のCPU使用率は100%になっているが、CPU使用率とメモリ使用量はPHP環境と同程度の負荷になっている ここまで確認して、プロファイラを使った方が良さそうに思えたので、いったんプロファイラで状況を確認するために、標準で提供されていて手軽に使えそうなpprofを使ってみました。topで確認すると次のような結果がでました。 (pprof) top 20 -cum 920ms of 15
とりあえず mycli と aws-shell のスクリーンキャストを見てください。 prompt_toolkit はこのようなリッチコンソールアプリを作るためのライブラリです。 Windows でも動きます。 Jupyter (ipython notebook) を切り離した、コンソール版の ipython も次のメジャーバージョンでは readline ベースから prompt_toolkit ベースに作りなおされています。 ipython 以外にも ptpython というシェルもあり、 ipython の各種 magic が不要な場合はこちらで十分でしょう。 https://github.com/jonathanslenders/python-prompt-toolkit#projects-using-prompt-toolkit には、他にも prompt_toolkit を採用
MySQLTuner is a script written in Perl that allows you to review a MySQL installation quickly and make adjustments to increase performance and stability. The current configuration variables and status data is retrieved and presented in a brief format along with some basic performance suggestions. MySQLTuner supports ~300 indicators for MySQL/MariaDB/Percona Server in this latest version. MySQLTune
オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日本オラクルに在籍していますが、本サイト(ブログ、またはウェブサイト)において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。 最近Windows上でmysqlコマンドラインツールを頻繁に使っている私です。 mysqlコマンドラインツールは、様々な起動オプションやコマンドを持っていますので、 なかなか全て覚えきれません。今日は対話的に利用する際に便利な二つのC(シー)を紹介します。 1. ¥c 2. Ctrl+c 1. ¥c mysqlコマンドラインで、コマンドを入力していて「実は全然思っていたのではなかった、取り消したい」 と思うときに使います。例えば、 mysql> alter table t1 add column
誤って、巨大なテーブルの全レコードを対象にするようなクエリを投げてしまって、いつまで経っても計算結果が返ってこないことってあるじゃないですか。そんなときの話。 mysql> show processlist; +----+------+---------------+------+---------+------+-------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+---------------+------+---------+------+-------+------------------+ | 9 | root | localhost | NULL | Query | 0 | NULL | show processlist | | 10
な、なんと person_diaryはインデックスが適用されずにフルスキャンされ(1行目のkeyがNULL) 逆にpersonはid列に設定してあるプライマリキーが適用される(2行目のkeyがPRIMARY) という二つの謎な現象が発生しました。 そもそもpersonはnameカラムに対してLIKE検索しているのに、id列のプライマリキーが効いちゃうのは全く納得いきません。なぜ、どうしてこんなことが起こるのでしょう? 原因 私がMySQLに期待していた動きとしては ①サブクエリを実行してperson.idのリストをメモリ中に作成 ②person.person_idに張られているインデックスを使って検索 というところでした。 期待通りに動いてくれなかったのには二つのMySQLの特性が関係していました。 特性① サブクエリを含むSQLは外側から先に実行される MySQLの場合、サブクエリを含む
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。 発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。 スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました そろそろ傷が癒えてきた。。 ISUCON5の本選にメルカリのインフ
平素より「PHPプロ!」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ!」ですが、サービスの利用状況を鑑みまして、2018年9月25日(火曜日)をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日(火曜日)を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く