Webアプリケーションを開発する上での設計パターンついてここで指してる設計パターンが何なのかというと、
なぜ設計が必要なのか 設計方針を決めないまま開発していると、個々それぞれの実装経験やドメイン知識などが異なるので
設計を導入することにより、どの機能はどこの書けばよいのかが明確になるので
現在の設計が機能しているかの判断ポイント 自分の経験上ですが、業務で扱う設計は以下のケースがあると思います
設計パターンを組み合せて利用してるケース 設計パターン + オレオレ設計のケース 完全オレオレ設計のケース そもそも設計自体を入れていないケース 設計自体を入れていないケース以外はどれが良いケースというのはケースバイケースなので明言できませんが
新しいドメインロジックを追加しようと思ってるけど何処に定義すればいいか迷ったりわからない 参照方法が幾通りある(例えば、DBデータを取得するのに、domain経由だったり、model経由だったりしてる) 重複してるコードが多いと感じる 各レイヤ間やドメイン間の依存関係が多い コントローラに業務ロジックなどのベタ書きが多いと感じる この処理は何処に定義するなどのルールが決まっていない 利用している設計について チーム開発では王道の「レイヤー化アーキテクチャ」を利用してます。
レイヤ化とは、依存の原則を強い制約を適用したアーキテクチャです。
大きな特徴としては
上位下位の関係になるように全体を分割する 上位レイヤは直下のレイヤにしかアクセスしないよう強制する 双方向の依存は禁止 こうすることで依存方向を一方向に限定できます
レイヤ化では、主な3つのレイヤに分けられます ・プレゼンテーションレイヤ WebアプリケーションではHTTP処理を行うレイヤになります。
・ドメインレイヤ データベースへのデータの登録、取得などの操作を行ったり、
・データソースレイヤ データベースへのアクセスロジック、取得したレコードのエンティティオブジェクト化、
レイヤー化アーキテクチャの設計パターンについて 上記でレイヤー化アーキテクチャについての概要を書きましたが
実際にはフレームワーク自体がすでに設計パターン取り入れてる場合もありますが
プレゼンテーションレイヤ このレイヤのパターン詳細は割愛します
コントローラ系のパターン
モデルビューコントローラ ページコントローラ フロントコントローラ ビュー系のパターン
トランスフォームビュー テンプレートビュー ツーステップビュー ドメインレイヤ 日本語訳では問題領域とされてて、非常に抽象的な表現なのですが
実装では機能として粒度の大きな単位をドメインモジュールで分割していき
横割りのフラット構造
1 2 3 4 5 6 7 8 9 10 11 12 13 domain ├── module1 │ ├── component1-1(service) │ ├── component1-2 │ └── component1-3 ├── module2 │ ├── component2-1(service) │ └── component2-2 └── module3 ├── component3-1(service) ├── component3-2 ├── component3-3 └── component3-4
横割りのネスト構造
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 domain ├── module1 │ ├── component1-1(service) │ ├── component1-2 │ └── component1-3 ├── module2 │ ├── component2-1(service) │ ├── component2-2 │ └── module3 │ ├── component3-1(service) │ ├── component3-2 │ └── module4 │ ├── component4-1(service) │ └── component4-2 └── module5 ├── component5-1(service) ├── component5-2 └── component5-3
縦割り構造
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 domain ├── service │ ├── component1 │ ├── component2 │ └── component3 ├── model │ ├── component1 │ ├── component2 │ ├── component3 │ ├── component4 │ └── component5 ├── entity │ ├── component1 │ ├── component2 │ ├── component3 │ └── component4 └── dao ├── component1 ├── component2 └── component3
とかがあります。
ドメインのパターンは以下に分類されます
・トランザクションスクリプト これパターンは、ドメインロジックを一連の手続きで定義していくパターンとなります。
1 2 3 4 5 6 7 8 9 10 11 def get_all_player_cards (player ): cards = {} cards['attack' ] = AttackPlayerCard.get_cards(player) cards['defense' ] = DefensePlayerCard.get_cards(player) cards['special' ] = SpecialPlayerCard.get_cards(player) return cards def get_strongest_attack_player_card (player ): player_cards = get_player_cards(player) player_cards.sort(key=operator.attrgetter('attack' ), reverse=True ) return player_cards[0 ]
・ドメインモデル このパターンは、目的や役割、関心などの括りをドメインモデルとして切り分けてオブジェクトで扱います。
このドメインモデルの実装は結構難易度が高いです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 def send_mail (user, message ): mailhandle = MailHandle() mailhandle.add(AdminMailHandler(user.name, message)) mailhandle.add(UserMailHandler(user.name, user.email)) mailhandle.send() class MailHandle (object ): def __init__ (self ): self .mail_handlers = [] def add (self, mail_handler ): self .mail_handlers.append(mail_handler) def send (self ): mailer = MailService() for m in self .mail_handlers: to_address = m.get_to_address() from_address = m.get_from_address() title = m.get_title() body = m.get_body() mailer.async_send(to_address, from_address, title, body) class MailStrategy (object ): __metaclass__ = ABCMeta @abstractmethod def get_to_address (): pass @abstractmethod def get_from_address (): pass @abstractmethod def get_title (): pass @abstractmethod def get_body (): pass class AdminMailHandler (MailStrategy ): def __init__ (self, user_name, msg ): self .user_name = user_name self .message = msg def get_to_address (): return 'admin@xxxx.com' def get_from_address (): return 'support@xxxx.com' def get_title (): return '問い合わせがありました' def get_body (): return '{} 様より 問い合わせがありました \n {}' .format (self .user_name, self .message) class UserMailHandler (MailStrategy ): def __init__ (self, user_name, to_address ): self .user_name = user_name self .to_address = to_address def get_to_address (): return self .to_address def get_from_address (): return 'support@xxxx.com' def get_title (): return '問い合わせ受け付けました' def get_body (): return '{} 様 \n 問い合わせ受け付けました' .format (self .user_name)
・テーブルモジュール このパターンは、データベース内のテーブルをドメインクラスで模倣するオブジェクトを用意するパターンです。
テーブルモジュールは複雑なビジネスロジックを実装するは苦手ですが、異なるデータソースからのデータを
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 class UserTableModule (object ): def __init__ (self, user ): self ._user = user self ._profile_kvs = ProfileKVS(user) self ._favorite_kvs = FavoriteKVS(user) @property def user (self ): return self ._user.to_dict() @property def profile (self ): return self ._profile_kvs.get() def create_profile (self, birthday, living, gender, comment ): init_data = {'birthday' : birthday, 'living' : living, 'gender' : gender, 'comment' : comment, 'type' : 1 , 'created_at' : datetime.datetime.now().strftime('%Y-%m-%d %H:%M' ), 'updated_at' : datetime.datetime.now().strftime('%Y-%m-%d %H:%M' )} self ._profile_kvs.save(init_data) def update_profile (self, profile_data ): profile_data['updated_at' ] = datetime.datetime.now().strftime('%Y-%m-%d %H:%M' ) self ._profile_kvs.save(profile_data) def get_favorite (self, data_id ): return self ._favorite_kvs.get_by(data_id) def get_favorites (self ): return self ._favorite_kvs.get_list() def create_favorite (self, target_id ): init_data = {'data_id' : str (uuid4()), 'target_id' : target_id, 'created_at' : datetime.datetime.now().strftime('%Y-%m-%d %H:%M' )} return self ._favorite_kvs.save(init_data) def delete_favorite (self, data_id ): return self ._favorite_kvs.delete(data_id) class ProfileKVS (object ): def __init__ (self, user ): self ._kvs = user.get_kvs(KVS_PROFILE_KEY) def get (self ): return self ._kvs.get() def save (self, profile_data ): self ._kvs.set (profile_data) class FavoriteKVS (object ): def __init__ (self, user ): self ._kvs = user.get_kvs(KVS_FAVORITE_KEY) def get_list (self ): return self ._kvs.get([]) def get_by (self, data_id ): return self ._kvs.get(data_id, None ) def save (self, data_id, data ): data_map = self ._kvs.get() data_map[data_id] = data self ._kvs.set (data_map) def delete (self, data_id ): data_map = self ._kvs.get() if data_map.get(data_id, False ): del data_map[data_id] self ._kvs.set (data_map)
・サービスレイヤ サービスレイヤはドメインロジックを構成する1つでドメインレイヤのインタフェースとなる部分で利用されます。
ドメインモジュール内のコンポーネントを外部と依存(直接参照)させないようにする 純粋なドメインロジックに外部レイヤからの呼び出しロジックも共存させると再利用の可能性が低下する サービスレイヤの実装パターンは2種類あります
ドメインファサード手法
操作スクリプト手法
データソースレイヤ ・テーブルデータゲートウェイパターン テーブルごとにデータへアクセスするためオブジェクトを用意するパターンです。
特徴としてはテーブルごとに1つのインスタンスを所持して、このインスタンス以外からデータへアクセスは行わない データベースからデータを取得するための数種類のfind、update、 insert、 deleteなどのメソッドから構成されるインタフェースを備えている データの受け渡しのみが役割であるためステートレスです データにアクセスするオブジェクトの振る舞いから短縮してDAOパターンとも呼ばれるてます ドメインパターンのテーブルモジュールパターンと組み合わせて利用されるケースが多いです 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 class PersonGateWayMixin (object ): @classmethod def _query_with_exception (cls, sql ): try : cls.db.execute(sql) except : return False return True @classmethod def find_all (cls ): sql = 'SELECT * FROM person' rows = cls.db.execute(sql) return rows if rows else [] @classmethod def find (cls, id ): sql = 'SELECT * FROM person WHERE id = {}' .format (id ) rows = cls.db.execute(sql) return rows[0 ] if rows else None @classmethod def find_by_age (cls, age ): sql = 'SELECT * FROM person WHERE age = {}' .format (age) rows = cls.db.execute(sql) return rows if rows else [] @classmethod def create (cls, **kwargs ): sql = 'INSERT INTO person VALUES ({}, {}, {})' sql = sql.format (kwargs['lastname' ], kwargs['firstname' ], kwargs['age' ]) return cls._query_with_exception(sql) @classmethod def update (cls, **kwargs ): sql = 'UPDATE person SET lastname = {}, firstname = {}, age = {} WHERE id = {}' sql = sql.format (kwargs['lastname' ], kwargs['firstname' ], kwargs['age' ], kwargs['id' ]) return cls._query_with_exception(sql) @classmethod def delete (cls, id ): sql = 'DELETE FROM person WHERE id = {}' .format (id ) return cls._query_with_exception(sql)
・行データゲートウェイ テーブルの1レコードを模倣するオブジェクトを用意するパターンです
特徴としてはテーブルの1レコードごとに1インスタンスを生成します オブジェクトにはテーブルの列と紐づくデータフィールドとアクセッサが定義されている オブジェクトの振る舞いは、insert, update, deleteを持ちます オブジェクトの振る舞いには、ドメイン系のロジックは定義しません。 find(検索)について
行データゲートウェイオブジェクトに静的findメソッドを追加して実装 findオブジェクトを定義して結果を行データゲートウェイオブジェクトにバインドさせる 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 def get_person (id return PersonFinder.find(id ) def get_person_by (age ): return PersonFinder.find_by(age) class PersonFinder (DBdriver ): @classmethod def find (cls, id ): sql = 'SELECT * FROM person WHERE id = {}' .format (id ) rows = cls.db.execute(sql) return PersonGateway(rows[0 ]) if rows else None @classmethod def find_by (cls, age ): sql = 'SELECT * FROM person WHERE age = {}' .format (age) rows = cls.db.execute(sql) if not rows: return [] return [PersonGateway(r) for r in rows] class PersonGateway (DBdriver ): def __init__ (self, **kwargs ): self .id = kwargs.get('id' , None ) self .lastname = kwargs['lastname' ] self .firstname = kwargs['firstname' ] self .age = kwargs['age' ] def _query_with_exception (self, sql ): try : self .db.execute(sql) except : return False return True def create (self ): sql = 'INSERT INTO person VALUES ({}, {}, {})' sql = sql.format (self .lastname, self .firstname, self .age) return self ._query_with_exception(sql) def update (self ): sql = 'UPDATE person SET lastname = {}, firstname = {}, age = {} WHERE id = {}' sql = sql.format (self .lastname, self .firstname, self .age, self .id ) return self ._query_with_exception(sql) def delete (self ): sql = 'DELETE FROM person WHERE id = {}' .format (id ) return self ._query_with_exception(sql)
・アクティブレコード 行データゲートウェイパターンとほぼ同じです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 class PersonGateway (DBdriver ): def __init__ (self, **kwargs ): self .id = kwargs.get('id' , None ) self .lastname = kwargs['lastname' ] self .firstname = kwargs['firstname' ] self .age = kwargs['age' ] @property def fullname (self ): return '{} {}' .format (self .lastname, self .firstname) def _query_with_exception (self, sql ): try : self .db.execute(sql) except : return False return True def create (self ): sql = 'INSERT INTO person VALUES ({}, {}, {})' sql = sql.format (self .lastname, self .firstname, self .age) return self ._query_with_exception(sql) def update (self ): sql = 'UPDATE person SET lastname = {}, firstname = {}, age = {} WHERE id = {}' sql = sql.format (self .lastname, self .firstname, self .age, self .id ) return self ._query_with_exception(sql) def delete (self ): sql = 'DELETE FROM person WHERE id = {}' .format (id ) return self ._query_with_exception(sql) @classmethod def find (cls, id ): sql = 'SELECT * FROM person WHERE id = {}' .format (id ) rows = cls.db.execute(sql) return cls(rows[0 ]) if rows else None @classmethod def find_by (cls, age ): sql = 'SELECT * FROM person WHERE age = {}' .format (age) rows = cls.db.execute(sql) if not rows: return [] return [cls(r) for r in rows]
まとめ ここまでPofEAA(Patterns of Enterprise Application Architecture)に元づいた設計パターンを
参考 ]]>
<p>Webアプリケーションを開発する上での設計パターンついて<br>ある程度自分の中で知見がまとまったのでつらつら書いてみる。</p>
<p>ここで指してる設計パターンが何なのかというと、<br>機能を開発するための業務ロジック設計ではなく<br>システム全体の構造の大枠を定義
Goでtreeコマンド
http://blog.fujimisakari.com/go_tree_command/
2017-08-10T00:00:00.000Z
2025-02-09T16:06:40.817Z
最近、Goでtreeコマンドを作ってみた。mkdir、touchしてから、ツリー構造の先頭に行きhttps://github.com/fujimisakari/go-tree
使い方は、yamlでtree構造を定義するだけです。go-tree以降からyamlの配列で定義していき、ディレクトリには末尾にセミコロン付けます。root-dirでrootディレクトリ名を定義することができます(defaultでは.になります)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 root-dir: "Sample" go-tree: - fizz - buzz - dir1: - comp1-1 - comp1-2 - comp1-3 - comp1-4 - dir2: - comp2-1 - comp2-2 - comp2-3 - comp2-4 - dir3: - comp3-1 - comp3-2 - dir4: - comp4-1 - comp4-2 - comp4-3 - comp3-3 - comp3-4 - comp2-5 - comp2-6 - dir5: - comp4-1 - comp4-2 - comp4-3 - comp4-4 - foo - bar
あとは、go-treeコマンドのパラメータにyamlファイルのpathに渡して実行。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 $ go-tree ./sample.yaml Sample ├── fizz ├── buzz ├── dir1 │ ├── comp1-1 │ ├── comp1-2 │ ├── comp1-3 │ └── comp1-4 ├── dir2 │ ├── comp2-1 │ ├── comp2-2 │ ├── comp2-3 │ ├── comp2-4 │ ├── dir3 │ │ ├── comp3-1 │ │ ├── comp3-2 │ │ ├── dir4 │ │ │ ├── comp4-1 │ │ │ ├── comp4-2 │ │ │ └── comp4-3 │ │ ├── comp3-3 │ │ └── comp3-4 │ ├── comp2-5 │ └── comp2-6 ├── dir5 │ ├── comp4-1 │ ├── comp4-2 │ ├── comp4-3 │ └── comp4-4 ├── foo └── bar
<p>最近、Goでtreeコマンドを作ってみた。<br>自分はディレクトリとファイルのツリー構造をREADMEなど仕様上の資料に含めることが多いのですが、<br>その際に必要とするディレクトリとファイルを<code>mkdir</code>、<code>touch</code>し
MySQLパフォーマンスチューニング
http://blog.fujimisakari.com/mysql_performance_tuning/
2017-08-06T00:00:00.000Z
2025-02-09T16:06:40.816Z
開発時にMySQLのパフォーマンスで気を付けてることのまとめました。メモリ設定 テーブル定義 クエリー発行 アプリケーション側 まとめ メモリ設定 MySQLは、データを保存するために利用するメモリとして
データキャッシュはSELECT文のキャッシュするための領域で
上記を踏まて、目的によって以下のデフォルトメモリのサイズをチューニングします。
データキャッシュ(バッファプール)innodb_buffer_pool_size: 128Mバイト ログバッファinnodb_log_buffer_size: 8Mバイト ログバッファのチューニングとしては、通常のWebアプリケーションでは
データキャッシュでは、単独のDBサーバだったら物理メモリの60〜70%ぐらい割り当てて
テーブル定義 INDEXについて ・INDEX効果 TABLEに対して発行される、SELECT句の種類に応じたINDEXは作らずINDEX効果が期待できるもののみを厳選します。
一般的には、INDEX効果が効く場合としては検索結果数が全体の5〜10%前後というのが目安で
・INDEX数 INDEXを貼ると「INSERT, UPDATE, DELETE」の速度が低下するので更新頻度が多いテーブルほどINDEXは少いほうがいいです。
・INDEX確認 たまにUNIQUE制約とINDEXを同時に同一カラムに定義してることがあるのでSHOW INDEX FROM <TabelName>;
パーティショニング 実際の運用ではデータが青天井で勢いよく増加つづけるテーブルが出てきます(解析系や履歴系とか)
よく利用するパーティショニングの種類は、Rangeパーティショニングでidやdateを利用して
クエリー発行 INDEXが期待できる条件を理解しておく ・INDEXが効くクエリー =, >, <, AND, IN, ORDER BY, GROUP BY, BETWEEN LIKE述語の前方一致のみSELECT * FROM account WHERE name like 'fuji%'; 索引列で右側で演算や関数を行っている場合select * from account where 50 > point * 1.1; ・INDEXが効かないクエリー 否定形(<>, !=, NOT IN) LIKE述語の中間一致、後方一致SELECT * FROM account WHERE name like '%fuji%';SELECT * FROM account WHERE name like '%fuji'; WHERE句で左側で演算や関数を行っている場合SELECT * FROM account WHERE point * 1.1 > 100;SELECT * FROM account WHERE LENGTH(point)b = 10; WHERE句でIs Null述語を使ってるSELECT * FROM account WHERE name IS NULL; *(ワイルドカード)のSELECT句 カラム数が多いテーブル or 大きなデータを持ってるカラムが存在するテーブルなどでは
JOINの仕組みを理解しておく JOINを利用する場合は仕組みを理解しておくことが重要と思ってます。
外部表100行と内部表100行の状態でINDEXが効かないJOINした場合100行 + 100行x100行 = 10100行のような計算量になります。100行 + 100行(100x1) = 200行となり無駄なく高速に処理できます。
JOINは外部表と内部表のかけ算になるのでパフォーマンスの観点から見ると
サブクエリーの使いどこ まず、サブクエリーは以下の問題点があるので積極的には使われない傾向があります。
可読性が悪い SELECT句にサブクエリー分のコストが上乗せされるので実行コストが増える サブクエリー結果からINやテーブル結合する場合、サブクエリー結果にインデック情報などを持たないので最適なパフォーマンスを得られない サブクエリー結果がすべてメモリに乗らなかった場合はSwapが発生し、急激な性能劣化が起きる サブクエリーが実行されて初めて結果がわかるので、事前にEXPLAINで実行計画を確認できない ということ問題があるので、SQL側で頑張って1クエリーで完結させようとせずに
・サブクエリーでパフォーマンスを改善できる場合 サブクエリーでパフォーマンスを改善の期待できるのは、
典型的なケースでは、1:Nの関係持った所属テーブルとユーザテーブルがある状況下で
パターン1: 所属テーブルとユーザテーブルをJOINしてからGROUP BYで絞る 1 2 3 4 5 6 7 8 9 10 11 12 SELECT g.id, g.name, SUM (u.group_id) AS user_count FROM `group ` AS g INNER JOIN user AS u ON g.id = u.group_id GROUP BY g.id
パターン2: サブクエリで事前にユーザテーブル対象を絞ってから所属テーブルとをJOINする 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 SELECT g.id, g.name, u.user_count FROM `group ` AS g INNER JOIN (SELECT group_id, SUM (group_id) as user_count FROM user GROUP BY group_id) AS u ON g.id = u.group_id
パターン1とパターン2では結合行数が異ります。
ただ、数百万件ぐらいの件数がないと、パターン1 < パターン2のパフォーマンスにならないと思います。
アプリケーション側 アプリケーション側でグルグル検索をしない(N+1) for文とかで都度クエリーを発行するとDBへの負荷が高いです。INを利用したクエリー結果で
1 2 3 4 for user in users: group = `SELECT * FROM group WHERE user_id = user.id ` detail = `SELECT * FROM user_detail WHERE user_id = user.id `
1 2 3 4 5 6 7 8 9 all_groups = {g.user_id: g for g in `SELECT * FROM group`} user_ids = [user.id for user in users] user_details = {d.user_id: d for d in `SELECT * FROM user_detail WHERE user_id IN (user_ids)` for user in users: group = all_groups[user.id ] detail = user_details[user.id ]
アプリケーション側のキャッシュを利用する DBへのクエリーを減らすためにアプリケーション側のミドルウェア(redisやmemcachedなど)
よくキャッシュ対象としてされるのは
頻繁に発行されるクエリー Primaryキーでの参照クエリー fixtureデータ系のフルスキャンクエリー 時間がかかる重いクエリー 基本はリードスルーのみでキャッシュ生成を行います。
SQL確認 アプリケーション側のデバッグツールでもSQLは確認できますが
確認するポイントとしては、
1リクエストで何回クエリーが発行されるかを見ます(30回以上であれば改善します) 1リクエストで重複してるクエリーを発行していないか確認します スロークエリーが発行されていないか確認します。(1秒以上のものがあれば改善します) MySQLの設定ファイルに以下を定義するとtmpから生SQLが確認できるようになります。
1 2 3 4 5 6 [mysqld] general_log=1 general_log_file=/tmp/sql.log slow_query_log=1 slow_query_log_file=/tmp/slow_sql.log long_query_time = 1
自分は開発中、tail -fでこのログを確認しながらパフォーマンス確認をしてます
まとめ 開発する際にパフォーマンスで気にしてることを棚卸し的に書いてみたけど、
どちらかというと、アプリケーションコードの可読性や保守性の方を一番大事にしてて
なので、できるだけアプリケーションの実装はシンプルになるよう心掛けて
参考 Bill Karwin
ミック
<p>開発時にMySQLのパフォーマンスで気を付けてることのまとめました。</p>
<ul>
<li>メモリ設定</li>
<li>テーブル定義</li>
<li>クエリー発行</li>
<li>アプリケーション側</li>
<li>まとめ</li>
</ul>
<h2 id="
