ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
MySQL 5.7で絶対に必要になると思うlog_timestampsの設定
気づかなかったけど、これ5.7.2から入ってたのか。 フツーに扱うDATETIME型(やその親戚)は time_zone 変数に支配されるけど、ログに出力される時刻は log_timestamps 変数に支配される。 この変数の取りうる値は UTC または SYSTEM で、暗黙のデフォルトはUTC 。。 mysql57> SELECT @@version; +---------------+ | @@version | +---------------+ | 5.7.5-m15-log | +---------------+ 1 row in set (0.00 sec) mysql57> SHOW GLOBAL VARIABLES LIKE '%time_zone'; -- タイムゾーンはフツーにJST +------------------+--------+ | Variable_
mysqlをdisる会 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このmysqlはサービスだから、まずsystemctl start mysqld して落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このタイトルを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、この記事をかいたんだ じゃあ、注文を聞こうか。 というわけでmysqlをdisります。disるだけな
MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響
攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 米Oracle傘下のオープンソースデータベース「MySQL」に未解決の脆弱性が見つかったとして、セキュリティ研究者が9月12日に概略やコンセプト実証コードを公開した。サイバー攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 研究者のDawid Golunski氏が公開した情報によれば、MySQLの脆弱性は複数発見され、、中でも特に深刻な1件については、リモートの攻撃者がMySQLの設定ファイルに不正な内容を仕込むSQLインジェクション攻撃に利用される恐れがある。 この脆弱性は、MySQLの最新版を含む5.7系、5.6系、5.5系の全バージョンに、デフォルトの状態で存在する。現時点でOracle MySQLサーバの脆弱性修正パッチは存在
PDOのサンプルで数値をバインドする際にintにキャストしている理由
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
雑なMySQLパフォーマンスチューニング
cvpaper.challenge の メタサーベイ発表スライドです。 cvpaper.challengeはコンピュータビジョン分野の今を映し、トレンドを創り出す挑戦です。論文サマリ作成・アイディア考案・議論・実装・論文投稿に取り組み、凡ゆる知識を共有します。 http://xpaperchallenge.org/cv/
Joomla!の「ゼロデイコード実行脆弱性」はPHPの既知の脆弱性が原因
Joomla!にコード実行脆弱性(CVE-2015-8562)があり、パッチ公開前から攻撃が観測されていたと話題になっています。 Joomlaに深刻な脆弱性、パッチ公開2日前から攻撃横行 「Joomla!」に再び深刻な脆弱性、3.4.6への速やかなアップデートを推奨 パッチ公開の前に攻撃が始まる状態を「ゼロデイ脆弱性」と言いますが、それでは、この脆弱性のメカニズムはどんなものだろうかと思い、調べてみました。 結論から言えば、この問題はJoomla!側に重大な脆弱性はなく、PHPの既知の脆弱性(CVE-2015-6835)が原因でしたので報告します。 exploitを調べてみる 既にこの問題のexploitは公開されていますが、悪い子が真似するといけないのでURL等は割愛します。以下のページでは攻撃の原理が説明されています。 Vulnerability Details: Joomla! Re
二千万レコードあるテーブルへのalterをサービスを止めずに流す | All Your Bugs Are Belong To Ass
※このエントリはMySQL Casual Advent Calendar 2015の5日目のエントリです。 openark-kit というものについて ここまで読んでわかった方は、この先を読む必要はありません。 openark-kitとは、mysqlの運用に便利なツールキットを14個あつめたソフトウェアパッケージです。 Shlomi Noachという方がPythonで開発しており、少なくとも2009年に発表されているようです。 2015-12-05時点での最新版は196.1となっており、.tar.gz および .deb で配布されております。 このエントリを書いた背景事情 そもそも僕自身、50を超えるクラスタ化されたmysqlノードと一緒に業務生活を送っております。 ところが、システムが非常に古くさい構成のため、合計レコード数が2億から3億程度ある垂直分割されたテーブルに対しALTERを投
A5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール
A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLとMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL
A5:SQL Mk-2を勝手に応援 - pochi-pの絵日記
A5:SQL Mk-2が超便利です。かなりお世話になってます。みんなも使うときっと幸せになれるよ！ このエントリは適当に色々書き連ねていく場所で、多分あとから加筆修正しまくります。 別エントリでも色々書きました。 ADO.NETとA5:SQL Mk-2の仲良しデバッグ SQLServerのsp_executesqlの実行文を、普通のSQLと擬似命令の記述へ変換するWebアプリ＆A5:SQL Mk-2用スクリプト こちらにダウンロードページ件Javascirpt版デモページを用意しています。 詳細説明は省くけど、見たらだいたい分かりますよね！ DMonkeyスクリプト版をA5:SQL Mk-2で実行したらこんな風にストリップした内容がエディタトップ（または選択範囲のトップ）に追加されます。 2015/11/14 ver0.0.3から元のsqlをコメントアウトして出力するようになりました。 2
「A5:SQL Mk-2」 - 強力な入力補完や実行計画の取得などで作業を大幅に効率化するフリーの高機能SQL開発環境
データベース開発支援用の高機能SQL開発環境。テーブル定義書をリバース生成したり、ER図を作成したりすることも可能。軽快に動作する。「A5:SQL Mk-2」は、リレーショナルデータベース（RDBMS）を操作・定義するための言語「SQL」を対話的に作成・編集・実行できるSQL開発環境。 強力なSQL入力補完機能、Insert入力支援機能を備えたSQLエディタパフォーマンス上、問題のありそうな個所を確認し、修正できる実行計画取得機能（PostgreSQL、MySQLなどに対応）インデントを制御したり、大文字・小文字変換したりできるSQL整形機能をはじめ、便利な機能を数多く搭載。SQLでの開発効率を大幅に向上させてくれる。Oracle、PostgreSQL、MySQL、SQLiteには直接、接続することが可能。そのほかのデータベースにもOCI、ADOまたはODBCなどを経由して接続できる。「A
MySQLでテーブル毎に設定されているストレージエンジンを確認する方法 - とあるSEの戯れ言
MySQLでは、各テーブル毎にストレージエンジンを設定する事が出来ます。 大体は、この２つのどちらかになるかと思います。 MyISAM：検索に強いらしい InnoDB：トランザクションが使えるらしい と言う事で、各テーブル毎に設定されているストレージエンジンを確認する方法です。 # mysql -u root mysql> use information_schema; mysql> select table_name, engine from tables where table_schema = DB_NAME; +--------------------+--------+ | table_name | engine | +--------------------+--------+ | hogehoge | InnoDB | | hagehage | MyISAM | | hige
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
そろそろSQLインジェクションについてひとこと言っておくか。 - だらだらやるよ。
ちょっとSQL Injectionについて未だに情報が少ないのにいらついていたので。 というか対策ばっかりで何ができますよーってのはほとんどログインできますよーくらいじゃねえか。 具体的な攻撃方法もわからずにぼんやり対策してるだけの人多いような気がするのでちょっと攻撃方法書いとく。 SQLインジェクションってなに？ アプリのユーザ入力領域からSQL文を注入されてしまうこと。 サーバでこういうコード書いてると、user_nameに「' or '1'='1';#」とか書かれて素敵なことになる。(mysqlの場合) String sql = "SELECT * FROM users WHERE = name = '"+user_name+"' AND password='"+user_password+"'"; 簡単に言うと、開発者の意図しないSQLをユーザの入力によって行う攻撃手法ですね。 S
クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
libmysqlclientを使うプログラムはset namesをutf8であっても使ってはいけない | へぼい日記
mysql_enable_utf8 => 1 で DBIC::UTF8Columns 要らなくなるっぽいComments 上記の記事のブクマに set namesを直接実行しちゃうのはutf8であってもコンパイルオプションによっては問題起こるのでお勧めできない http://b.hatena.ne.jp/nihen/20090204#bookmark-11950629 ってことを書かせてもらったんだけど、この最後のset namesはutf8でも使っちゃダメという話を軽く説明します。 まずは、基本的なことはMySQL5開拓団 – 日本語処理の鉄則 / KLab株式会社を読んでください。mysqlの日本語処理についてのドキュメントとしては、私は今一番信頼できるドキュメントだと思っています。 さて、上記のページの< 図3：クライアント側文字コードの指定チャート>を、勝手ながらすべて引用させてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2大OSSデータベースのMySQLとPostgreSQLの違い(後半)
2大OSSデータベースのMySQLとPostgreSQLの違い(前半)
MySQL: INSERT...ON DUPLICATE KEY UPDATEまとめ - Qiita
