セッションハイジャックを防ぐ7つの方法

会社のブログに寄稿させていただきました。
PHPのセッション情報をデータベース(MySQL)に保存するぜ!

こちらの記事ではセッション情報をDBサーバーに保存させて、ロードバランサーで接続するサーバーが切り替わってもセッションが維持される方法について記載しましたが、セッションハイジャックについては言及しておりません。ということで今回はセッションハイジャックを防ぐ方法について紹介します。

この記事を読む ≫

MySQLで使ってないインデックスを調べる方法

MySQL5.5から統計情報を収集するperformance_schemaというテータベースが利用できるようになりました。そしてMySQL5.6ではperformance_schemaデータベース内にtable_io_waits_summary_by_index_usageというテーブルが追加されていました。

え!?これってもしかしてインテックスの使用状況がわかるんじゃない?って期待が頭をよぎりましたので調べてみました。

この記事を読む ≫

InnoDBの8KBの壁にぶち当たったら。

InnoDBの行の最大長は約8KBらしい。

意外と少ない。。。

運用中のサービスがこんなエラーを吐いていました。。。

Got error 139 from storage engine

マジですか。これが噂の「InnoDB 8KBの壁」ですか。。。

設計段階であればテーブル縦分割とかテーブル構造自体を変えちゃえ!ってなるかもしれないですが、運用中のサービスですし、できるだけ全体へのインパクトは少なくしたい(アプリケーションは改修したくない)。って時にテーブルのROW_FORMATを変更して対応しましたよ、って話です。

この記事を読む ≫

MySQLのログに InnoDB: Error: Table “mysql”.”innodb_table_stats” not found. て出てた時の対処法

MySQLのログにエラーが出力されておりました。

2014-11-12 20:58:34 7ff0ac4fb700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found.
2014-11-12 20:58:34 7ff0ac4fb700 InnoDB: Recalculation of persistent statistics requested for table "wordpress"."wp_commentmeta" but the required persistent statistics storage is not present or is corrupted. Using transient stats instead.

まあ、Wordpressは問題無く動いているし、「Wordpressのアップデートミスったかなぁ。ストレージエンジン変更しまくってたし、またいつかリストアでもしよ。」なんて考えていたのですが、同じ問題にぶち当たっている人がいたので、見てみたところMySQL5.6のバグらしいとのこと。

この記事を読む ≫

MySQLユーザーとinformation_schemaデータベースについて

information_schemaデータベースについてリファレンスマニュアルの抜粋。

INFORMATION_SCHEMA provides access to database metadata, information about the MySQL server such as the name of a database or table, the data type of a column, or access privileges. Other terms that are sometimes used for this information are data dictionary and system catalog.

INFORMATION_SCHEMAは、データベース・テーブルの名前、カラムのデータ型やアクセス権限といったMySQLサーバーの情報を持ったデータベースのメタデータへのアクセスを提供します。この情報は時々「データディクショナリ」や「システムカタログ」といった別の用語が使用されます。

引用元: MySQL 5.6 Reference Manual :: 21 INFORMATION_SCHEMA Tables

ユーザーの権限によってinformation_shemaの見え方がどのようになるのか気になったので、試してみました。

環境:MySQL 5.6.16

この記事を読む ≫

ビットフラグをDBのテーブル設計に用いてみる

DBのテーブル設計を行うときにフラグを持つフィールドは、それぞれtinyint(1)とかでフィールドを作って0 or 1を入れるようにしていました。

CREATE TABLE `sample_old` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
    `flg1` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'フラグ1',
    `flg2` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'フラグ2',
    `flg3` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'フラグ3',
    `flg4` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'フラグ4',
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

これだとテーブルに持つフラグが増えた分だけフィールドの数も増えますし、検索SQLのWHERE条件も増えてしまうのどうしようって思っていたら、ビットフラグ使えばいいよねって話になったので試してみます。

動作確認環境:MySQL5.6

この記事を読む ≫