詳説 MySQLで累積和を求める方法
mysql-accumlate.md MySQL で累積和を求める方法 MySQL で累積和を求める - 私が歌川です 日ごとの保存した画像の枚数とその累積を取るSQL 画像1枚とテーブルの1行が対応付いている 変数は邪道なので使いたくない SELECT t1.accum_date , t1.count , SUM(t2.count) AS accum FROM ( SELECT DATE(created_at) AS accum_date , COUNT(*) AS count FROM images GROUP BY accum_date ORDER BY accum_date ) AS t1 JOIN ( SELECT DATE(created_at) AS accum_date , COUNT(*) AS count FROM images GROUP BY accum_date
MySQLのslow_logは何を計測して出力されるのか - tom__bo’s Blog
slow logの時間は何を計測しているのか？ きっかけ とあるMySQLインスタンスで1Gbのネットワーク帯域を使い切ってレスポンスタイムが悪化していたという話を聞いた。 確かに遅いがlong_query_timeを小さくしてもslow_logは特に出ていなかったため、どのクエリが問題なのかを特定しづらかったらしい。 これを聞いたときはRedisとかインメモリのDBならまだしもMySQLがストレージより先に1GbのNICを使い切ることがあるのかーと驚いた。まあ、100GB以上のメモリも珍しくないので、ほとんどメモリから結果を返していれば1Gb/s以上返すことは難しくなさそうではある。 だが、long_query_timeを小さくしてもslow_logにクエリが出力されなかったという部分は気になった。 具体的にlong_query_timeがどれくらいなのか、同時接続数はどれくらいでQPS
MySQL Challenge: 100k Connections
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
MySQLのFLOAT型を使う理由が見つからない件 - hnwの日記
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型（32bit）で実現されます*1。
MySQL 5.7のONLY_FULL_GROUP_BYはちょっと進化してた - かみぽわーる
このエントリはMySQL Casual Advent Calendar 2015の14日目です。 TL;DR MySQL 5.7ではデフォルトONLY_FULL_GROUP_BYが有効である。MySQL 5.7.5からONLY_FULL_GROUP_BYが有効のとき GROUP BY句のカラムと関数従属性のあるカラムはSELECT句に書けるようになった😤 ORDER BY句のカラムはDISTINCTのカラムリストに含めなければいけなくなった😣 ONLY_FULL_GROUP_BYを無効にしなくてもHAVING句のalias拡張が使えるようになった😆 GROUP BY句のカラムと関数従属性のあるカラムはSELECT句に書けるようになった [mysqlcasual] > CREATE TABLE users (id int unsigned auto_increment primary
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！）
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！） 【2016/01/13 10:12】 MySQL 5.7.11でdefault_password_lifetimeのデフォルトは0に変更になりました！ それ以降のバージョンであればこの記事の内容は気にする必要はありません。 日々の覚書: MySQL 5.7.11でdefault_password_lifetimeのデフォルトが0になるらしい！ TL;DR default_password_lifetime= 0 を秘伝のmy.cnfに入れておくつもり。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables パラメーターの意味は読んで字のごとく、「最後にパスワードが更新さ
MySQL5.6にしていくつかのSQLでエラーが出るようになった - SEEDS Creator's Blog
MySQL5.6にしていくつかのSQLでエラーが出るようになっちゃいました。 具体的にはINSERT文を実行した時、以下のようなエラーとなり処理が実行されなくなりました SQLSTATE[HY000]: General error: 1364 Field 'hoge' doesn't have a default value エラー文からデフォルトバリューが設定されてないカラムにNULLを入れようとした為のエラーのようです。 ぐぐるとずばりな回答をされてるブログが見つかりました。 iをgに変えるとorangeになることに気づいたoranieの日記 MySQL5.6で今までのVerでは問題無かったSQL文がエラーになった場合の対処法 http://d.hatena.ne.jp/oranie/20130402/1364906656 日々の覚書 MySQL5.6が勝手にsql_modeを書き換え
MySQL5.6で今までのVerでは問題無かったSQL文がエラーになった場合の対処法 - oranie's blog
追記：記事の文中で5.6のsql_modeデフォルト値について若干実際の挙動と異なる表記をしていました。rpmでinstallすると/usr/my.cnfというのがひょっこりいて、この中に [mysqld] sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES という記述があり、これを/etc/my.cnfと合わせて設定している様です。で、デフォルト値については5.6.6以降はデフォルト値が「The default SQL mode in MySQL 5.6.6 and later is NO_ENGINE_SUBSTITUTION;」でそれ以前のデフォルト値は「MySQL 5.6.5 and earlier, it was empty (no modes set)」となっているようですね。 詳しくは http://yoku0825.blo
MySQL 5.6と5.7のInnoDBバッファプールウォームアップのおはなし | GMOメディア エンジニアブログ
こんにちは、DBAです。 MySQL 5.6でInnoDBのバッファプールウォームアップが機能追加されました。みなさん使ってますか？ MySQL 5.6では正常終了時のダンプも起動時のロードもオフ、対してMySQL 5.7では両方ともオンです。また、MySQL 5.7ではダンプするバッファプールのページ数は(デフォルトでバッファプール全体の25%だけ、となっています。 わたしのオススメ設定は↓です。MySQL 5.6, 5.7両方でも使えるように、loose-接頭辞付きでinnodb_buffer_pool_dump_pct(5.7にあって5.6にないパラメーター)を書いています。 [mysqld] loose-innodb_buffer_pool_dump_pct = 100 innodb_buffer_pool_dump_at_shutdown= 1 innodb_buffer_poo
MySQL5.5のレプリケーションでスレーブがSlave_IO_Running: Connectingとなってしまう - ponkiti's blog
このサイトを参考にレプリケーションを進めたが、MySQL5.1（マスター・スレーブ共に5.1、yum install）でのレプリケーションはうまくいったのだが、MySQL5.5（ソースインストール）同士でのレプリケーションはスレーブ側でSlave_IO_Running: Connectingとなってしまった。 mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Connecting to master Master_Host: 192.168.33.12 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysqld-bin.000001 R
CHANGE MASTER TO
久々にkagoya vpsのテスト環境にログインしてみたら・・・mysqlがとまっとる！！！ 何か少し前にサーバーの再起動を行います的なメールが来ていたので、 その影響で止まっていたのかな？ 早速、起動を試した際におきた問題の話です:(；ﾞﾟ'ωﾟ'): masterは簡単に起動できたのですが、 slave側で起動後にslave startを実行してみたらエラーになってしまいました。 エラー内容は次のような内容になっていました。 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Master_Host: *********** Master_User: slave Master_Port: 3306 Connect_Retry:
my.cnfの設定例 – OpenGroove
my.cnfの設定例について。以下、重要と思われる箇所をピックアップしてみた。 特に指定がない限り[mysqld]セクションの記述。値はあくまで例。 基本的なパラメータ [mysqld] user = mysql ←MySQLインスタンスの実行OSユーザがmysqlになる。 basedir = /usr/mysql ←MySQLバイナリのインストールディレクトリ。 datadir = /data/mysql ←DB領域のトップディレクトリ。新規DBが置かれる。 port = 3306 ←インスタンス起動時TCP/IP接続の受付ポート。 socket = /data/mysql/mysql.sock ←ローカルからの接続時に使用するソケットファイルの指定。 基本的にMySQLインスタンスの起動はrootかユーザmysqlで行う。 どちらにしてもプロセスオーナーはmysqlとなる。 datad
mysqlslapで手軽にテストデータを用意する | Urban Theory
久しぶりの投稿第1段は、負荷エミュレーションツールのmysqlslapを使って手軽にテスト用データを作成するという内容です(MySQL5.5以降に付属のmysqlslapが必要)。 実行方法とパラメータの意味 例：約10万件のデータを作成 mysqlslap -u mysqlslap -p --create-schema=mysqlslap -a --no-drop \ --auto-generate-sql-add-autoincrement --auto-generate-sql-load-type=write \ --number-int-cols=2 --number-char-cols=2 \ --auto-generate-sql-secondary-indexes=3 \ --auto-generate-sql-execute-number=1000 --auto-gener
vagrantでmysqlレプリケーション実験環境をお手軽作成
mysqlのレプリケーション設定をする機会があったので、実環境で試す前に実験してみたいと思い、vagrantを使ってレプリケーション設定用のサーバを立ててみました。 結構長くなってしまいましたが、手順をまとめておきます。 vagrantを使うと手軽に実験環境を作れていいですね。 目標マスター1台、スレーブ1台のレプリケーション設定をするDBはmysql5.5を使用vagrantで複数のvmを作成する適当にディレクトリを追加mkdir -p ~/Vagrants/repl/ cd ~/Vagrants/replvagrant初期化vagrant initVagrantfile修正db_masterとdb_slaveの設定を追加 vi Vagrant Vagrant::Config.run do |config| config.vm.box = "base" config.ssh.timeou
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LT：MySQLのギャップロックとネクストキーロックについて
GitHub - Percona-Lab/mysql_random_data_load: MySQL random data loader
pixivにおけるMySQL運用の実際
MySQL 5.7入門(レプリケーション編)