タグ

*MySQLに関するyamadarのブックマーク (228)

  • MySQLのメモリ使用量に関するトラブルシューティングTips | Yakst

    MySQLが確保する各種メモリに関するパラメータの概要から、それらがどのように割り当てられるのかを知るための様々な手法まで、Perconaのサポートエンジニアが詳しく解説する。 January 24, 2014 By Nilnandan Joshi 「MySQLサーバのメモリ使用量」に関連するトピックスを書いたブログ記事は既にたくさんあるにも関わらず、MySQLのメモリ関連の問題のトラブルシューティングで混乱しなかった人はいないだろう。Perconaサポートのエンジニアとして、高負荷のサーバに関することや、メモリ使用量高騰でOOM killerが発動してMySQLサーバが停止したこと、あるいは「MySQLがどうしてこんなにメモリをうのか分からない。どうやったら何にメモリが使われてるか分かるんだ?助けてくれ!」と言った問題を数多く見ている。 MySQLのメモリ使用量をチェックする方法はたく

    MySQLのメモリ使用量に関するトラブルシューティングTips | Yakst
  • データベース名を変更するには | RISIN'

    2011-02-28  mysql 一度作成したデータベースの名前を変える方法です。バージョンは5.1.41です。 MySQL 5.1.7以前では、RENAME DATABASEを使えば簡単にできたのですが、危険を伴うため5.1.23からこのクエリは使えなくなっています。 This statement was added in MySQL 5.1.7 but was found to be dangerous and was removed in MySQL 5.1.23. It was intended to enable upgrading pre-5.1 databases to use the encoding implemented in 5.1 for mapping database names to database directory names (see Section

    データベース名を変更するには | RISIN'
  • [MySQL] “Reading table information for completion of table and column names”ってなにかを教えちゃいますの巻

    MySQLサーバーにMySQLコマンドでアクセスしてMySQLコマンド「use データーベース名」で使用するDBを切り替えた時に確認されたメッセージが気になったのでちょっとだけ調べてみました。結果スッキリ出来たのでここに共有します。 今までDBの切り替えを行った場合以下のメッセージを確認していましたが、特に気にしていませんでした。以下はMySQLサーバーへログイン後「use mysql」を実行し、データーベース名が「mysql」のDBに切り替えた時のメッセージです。 mysql> use mysql Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed

    [MySQL] “Reading table information for completion of table and column names”ってなにかを教えちゃいますの巻
  • MySQL Casual Talks Vol.8 でMySQL 5.7とMariaDB 10.1の性能比較について発表しました - hiroi10のブログ

    はじめに 遅くなりましたが11/20(金)に開催されたMySQL Casual Talks Vol.8で以下スライドで発表しました。その内容の補足とかを載せておきます。 MySQL5.7とMariaDB10.1の性能比較(簡易) from hiroi10 最近MariaDB 10.1がGAになり、MySQL 5.7がGAになり、MariaDBってどうなん?、とか聞かれる事が増えたためとりあえずベンチマークで性能比較してみよう、が発端でした。MariaDBの10系はMySQL 5.5をベースにしているということで正直あまり期待していなかったのですが、起動時のログを見るとInnoDBはPerconaのXtraDB5.6ベースだったのでPercona5.6と同じ傾向かなぁという想像で実施しましたが概ね同じ傾向となりました。 まず、私はMariaDB10系はまともに触ったことがなかったので変だなと

    MySQL Casual Talks Vol.8 でMySQL 5.7とMariaDB 10.1の性能比較について発表しました - hiroi10のブログ
  • MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響

    攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 米Oracle傘下のオープンソースデータベース「MySQL」に未解決の脆弱性が見つかったとして、セキュリティ研究者が9月12日に概略やコンセプト実証コードを公開した。サイバー攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 研究者のDawid Golunski氏が公開した情報によれば、MySQLの脆弱性は複数発見され、、中でも特に深刻な1件については、リモートの攻撃者がMySQLの設定ファイルに不正な内容を仕込むSQLインジェクション攻撃に利用される恐れがある。 この脆弱性は、MySQLの最新版を含む5.7系、5.6系、5.5系の全バージョンに、デフォルトの状態で存在する。現時点でOracle MySQLサーバの脆弱性修正パッチは存在

    MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響
    yamadar
    yamadar 2016/09/13
    前提として任意のSQLが実行できる事(SQLインジェクション含む)なので、そこそこハードル高い。
  • 更新処理に関わる参照 SQL はマスタ DB を参照するようにカスタマイズする - Qiita

    こんにちは。2015年 FuelPHP Advent Calendar 20日目を担当させて頂く @uzura8 です。 昨日は @goosys さんの「EAVコンテナでカスタムフィールドっぽいことをする」でした。 私は普段業務でプログラミングしていない趣味エンジニアです。暇な時に OSS の SNS エンジン(https://github.com/uzura8/flockbird) を開発してます。技術ブログも書いたことないので若干不安ですが、宜しくお願いします。 さて日は DB 関連のカスタマイズについてです。 参照系の負荷分散の為、 master/slave 環境がよく使われますが(最近はどうなんでしょう?)、FuelPHPも複数 DB に対応しています。 * 参考: fuelPHPMySQLのREPLICATION (Master-Slave)を使う 参照時の接続先を明示的に指

    更新処理に関わる参照 SQL はマスタ DB を参照するようにカスタマイズする - Qiita
  • ヤフー社内でやってるMySQLチューニングセミナー大公開

    速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)NTT DATA Technology & Innovation

    ヤフー社内でやってるMySQLチューニングセミナー大公開
  • MySQLのSHOW TABLE STATUSに騙された - Qiita

    rowsが違うんですが・・・ テストしてて気付きました。 rowsを早く知りたくて show table status を使っていたのですが、実は適当な値だったのです。 膝から崩れ落ちそうになりました。 コンソール ※ 固有名などはマスクしています [root@hoge batch]# mysql -uroot -proot --database=my_work mysql> show table status; +-----------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+-------

    MySQLのSHOW TABLE STATUSに騙された - Qiita
    yamadar
    yamadar 2015/11/25
    行をカウントする時、show table status の rowsは正しくないことがある。select count(*) を使う。
  • MySQL 5.7の新機能完全リスト | Yakst

    MySQL 5.7には150を超える新機能がある。 MySQLのマニュアルはとてもいいものだが、少し長すぎる。これは、新機能の箇条書きリストだ。それぞれの機能について1つずつまとめるように頑張ってある。なので、 InnoDBのネイティブパーティショニング については、InnoDBの項かパーティショニングの項のどちらかにだけ載っている。 MySQL 5.7.8 RC2はここからダウンロードできる それか、yumかaptのリポジトリーからもインストール可能だ。 レプリケーション関連 マルチソースレプリケーション(訳注: 1スレーブに複数マスターを設定可能になった) [ 1 ] オンラインでのGTIDの有効化 [ 1 2 3 ] 準同期レプリケーションの性能向上 [ 1 2 ] ロスレス準同期レプリケーション [ 1 2 ] 準同期レプリケーションでいくつのスレーブからACKが返ってくるまで待つ

    MySQL 5.7の新機能完全リスト | Yakst
  • MySQLでクエリの実行時間を手っ取り早く計測する | きーたろう QiitaAPIで検索しちゃう!

    yamadar
    yamadar 2015/07/22
    MySQLサーバー内のレスポンスタイムではなく、アプリケーション・サーバーから見たクエリの実測時間(ネットワーキング時間込み)を知る方法
  • MySQL5.6でクッソ遅くなるSQL実行しました - Glitch

    MySQL5.6.3から、FROM句サブクエリにおける一時テーブルで、インデックスが作成されると聞いたので、テストしてみた。 MySQL :: MySQL 5.6 Reference Manual :: 8.13.16.3 Optimizing Subqueries in the FROM Clause (Derived Tables) 比較対象はMySQL5.5.32とMySQL5.6.12です。 SELECT * FROM (SELECT * FROM test_tbl) y WHERE col3=3; 正直こんなSQL発行するなっていう文ですが。 対象テーブルtest_tblはこんなかんじ。 CREATE TABLE `test_tbl` ( `col1` int(11) NOT NULL AUTO_INCREMENT, `col2` varchar(10) DEFAULT NULL

    MySQL5.6でクッソ遅くなるSQL実行しました - Glitch
  • 5分で出来るMySQLのお手軽チューニング - わーくあうと!

    こちらのエントリーで書いているのですが、開発用のVPS鯖がメモリ使い過ぎで重くなっていて、mysqlに問題がありそうだったのでサクっと調整しました。 その手順を残しておきます。 MySQLのチューニング項目について説明 MySQLのメモリに関する設定項目はたくさんあります。 それぞれの項目に関しての詳しい情報は下記が参考になります。 http://trackback.blogsys.jp/livedoor/klab_gijutsu2/50860867 ただ、これらを全て把握するのは大変だと思うので、簡単に分類すると以下の2種類があります。 グローバルバッファ スレッドバッファ で、MySQLが使うメモリ量は下記になるわけです。 グローバルバッファ + ( スレッドバッファ * コネクション数 ) それらを踏まえた上で具体的なチューニングに入ります。 MySQLで使っているメモリ量を調べる

    5分で出来るMySQLのお手軽チューニング - わーくあうと!
  • MySQLのメモリ設定の勘所 – sawara.me

    MySQLサーバーをダウンさせた夜は数知れず。 その度にmy.cnfの設定を見なおしてみてはトライし、治ったと思いきや突然のダウン。 サーバーがダウンしてしまう原因は何かと聞かれれば、「メモリです」と断言しましょう。 メモリ設定は諸刃の剣。 パフォーマンスを最大に引き出すこともできればそれと引き換えにサーバーをダウンさせてしまうこともできるんです。 今回はMySQLのメモリの設定の勘所というかたちで紹介しようと思います。 グローバルバッファとスレッドバッファ メモリの設定についてまず「グローバルバッファ」と「スレッドバッファ」について理解しておくことが大事です。バッファとは一時的な記憶領域・つまりはメモリの領域のことなのですが。 グローバルバッファ MySQLで使用する全体的なメモリ使用量を計算するには グローバルバッファ + (スレッドバッファ × コネクション数) = メモリ使用量 と

    MySQLのメモリ設定の勘所 – sawara.me
  • ルーク!MySQLではkamipo TRADITIONALを使え! | おそらくはそれさえも平凡な日々

    よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI

    ルーク!MySQLではkamipo TRADITIONALを使え! | おそらくはそれさえも平凡な日々
  • RDBにおけるキャッシュという考え方

    RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題(クエリ)を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ(アプリケーションの設計者)に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ

    RDBにおけるキャッシュという考え方
  • 実録MySQLのチューニング 春の陣 - (ひ)メモ

    long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです! 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソースい潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,

    実録MySQLのチューニング 春の陣 - (ひ)メモ
  • 大人のためのInnoDBテーブルとの正しい付き合い方。

    InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか?」というものがある。InnoDBMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T

    大人のためのInnoDBテーブルとの正しい付き合い方。
  • MySQL InnoDBストレージエンジンのチューニング(後編)

    チューニングの基礎 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。 バッファプール 最も基となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。 innodb_buffer_pool=32G ここで一つ注意がある。innodb_buffer_pool_sizeはバッファプー

    MySQL InnoDBストレージエンジンのチューニング(後編)
  • InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる!

    MySQL 5.1.38からMySQL体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ!」もしくは「検証してるよ!」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ?!という人が多いんではないかと思うのだが、実際はどうなのだろう?現在はRC版(リリース候補版)という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将

    InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる!
  • InnoDBの8KBの壁にぶち当たったら。 – sawara.me

    InnoDBの行の最大長は約8KBらしい。 意外と少ない。。。 運用中のサービスがこんなエラーを吐いていました。。。 [code gutter=”false”] Got error 139 from storage engine [/code] マジですか。これが噂の「InnoDB 8KBの壁」ですか。。。 設計段階であればテーブル縦分割とかテーブル構造自体を変えちゃえ!ってなるかもしれないですが、運用中のサービスですし、できるだけ全体へのインパクトは少なくしたい(アプリケーションは改修したくない)。って時にテーブルのROW_FORMATを変更して対応しましたよ、って話です。 「ROW_FORMAT=DYNAMIC」または「ROW_FORMAT=COMPRESSED」を使おう! そうです、結論から言ってROW_FORMATを変更することで対応したんです。 ROW_FORMATについてMyS

    InnoDBの8KBの壁にぶち当たったら。 – sawara.me