ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程 RDS の新しい高可用性オプションである Multi-AZ DB Cluster が一般提供となったためレポートします。Multi-AZ DB Cluster は従来の高可用性オプションの Multi-AZ DB Instance と比較して書き込み性能の向上とフェイルオーバーの高速化が期待できるオプションです。 New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failover なおプレビュー時の紹介はこちらのエントリーです。 Multi-AZ DB Cluster RDS には従来高可用性のためのオプションとして Multi-AZ Instance がありました。従来の Mu
はてなブログに投稿しました #はてなブログ Re: 結局、Go言語をやめる理由はなかった件 - Hateburo: kazeburo hatenabloghttps://t.co/JXxHpQrsZb— kazeburo@スタンドの時間です�! (@kazeburo) 2020年12月17日 素晴らしい内容のエントリですね。 https://kazeburo.hatenablog.com/entry/2020/12/17/164857 ここで出てくる「秘伝のタレ」とはなんなのか?久しぶりにmy.cnf見て意味忘れていたので自分の復習というコバンザメエントリです。 それぞれの内容はオフィシャルドキュメントを確認するのが一番正確です。 innodb_doublewrite = 0 https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters
max_allowed_packetについて max_allowed_packetとは、通信時における1パケットの最大サイズ。BLOB型(画像などのバイナリを入れるカラム)を利用する場合、最大BLOBカラム長より大きく設定する必要があります。 DBD::mysql::st execute failed: Got a packet bigger than 'max_allowed_packet' bytes at /usr/local/yaruo/mysal/DBI.pm line 347max_allowed_packetが小さいとエラーが出力されます。 max_allowed_packetの確認方法 下記結果は、16Mで設定している状態です。 mysql> show variables like 'max_allowed_packet'; +--------------------+--
Linux/Unix/Open Source Software related Mailing-List Log http://MLog.euqset.org/ 試験運用中 [mysql 14379] Re: Workbench(Windows)からMySQL(Linux)へのデータベース接続について かじやまです。 現在のMySQL Workbench Community Edition (OSS)では、 稼働中のMySQLから直接リバースエンジニアリングを行う 機能が使用できなくなっております。 #昨年11月にEditionごとに利用できる機能に差ができる旨が発表されました � http://dev.mysql.com/workbench/?p=13 機能の比較表は下記ページの中段以降に記載してあります。 http://dev.mysql.com/workbench/
MySQL Workbench is a unified visual tool for database architects, developers, and DBAs. MySQL Workbench provides data modeling, SQL development, and comprehensive administration tools for server configuration, user administration, backup, and much more. MySQL Workbench is available on Windows, Linux and Mac OS X. Design MySQL Workbench enables a DBA, developer, or data architect to visually design
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
ストレージエンジンとしてInnoDBを使うときはMyISAMのときと触るべきポイントが違うので注意。 http://www.mysqlperformanceblog.com/files/presentations/OSCON2004-MySQL-Innodb-Performance-Optimization.pdf を読みながら取ったメモ。状況としてはRedHat AS3.0で動かしたときのDBT2*1のパフォーマンスを改善していくというもの。MySQL デフォルト状態での分析 Handler_read_nextが多い、つまりrange scanかindex scanが多すぎる slow query logで何が悪いかを引っかける 例では2秒以上処理にかかったqeuryを記録するようにしている 結果を分析 update文が遅かったけど、update文そのままではexplainできないので、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く