SkillSet - 利用者の投稿記録 [ja]

Apache HTTP Server

2026-04-27T00:06:53Z

Y: /* セキュリティ */

[[ファイル:apache.png|thumb|Apache|300px]]
[[ファイル:port.png|thumb|港の配送センター|300px]]

'''Apache HTTP Server''' とは手元のマシンを港 (配送センター) にするためのソフトウェア。C言語製。Apache を城に導入してインターネットに広く公開するとその城は「港 / 公開サーバ」になる。WWW の世界は膨大な数のWebマシンたちの膨大な量の働きによって支えられている。

ちなみに、「人気な港」になると日本中から注文リクエストが殺到することになるので、それを効率よくさばくためのチューニングが必要になったりする。高品質な Service を serve する Server/Servant になる。

==公式の説明書==
* [https://httpd.apache.org/docs/2.4/en/ Apacheドキュメント]

==注文ログ==
# cd /var/log/apache2
# tail -f access_log

数分見ているだけで本当に色々な注文がくる。そして正当な注文は少ない笑。

==セキュリティ==
* security2-module を入れる
* ServerTokens を Prod にして表示を「Apache」だけにする
* Options で -Indexes指定してフォルダ一覧を非表示
* 他マシンからのリソースの使い回し要求を拒否する

===Next.js関係===
* Next.js を Apache でリバプロしてる場合、evasive 入れるとブラウザからの複数リクエストが Dos扱いになりデータが一部表示されなくなるのでブロックされるので入れない

===WordPress関係===
xmlrpc攻撃の遮断。めちゃくちゃ接続リクエストくるので /etc/apche2/apache2.conf に追加。

<Files "xmlrpc.php">
Require all denied
</Files>

==キャッシュ==
キャッシュを使えばサーバが全てのレスポンスに対応する必要がなくなる。つまり、サーバの負担が軽減する。キャッシュは Webサービスの主要な構成要素。

# 共有キャッシュ - 専用サーバなど
# プライベートキャッシュ - ブラウザ内など

キャッシュには上記２種類があり、サーバに比べていずれもクライアントに近い場所にあるので毎回サーバからダウンロードするよりもレスポンス速度が向上する。

コンテンツの更新頻度とのバランスを考えながら上手にキャッシュを使えば、高いパフォーマンスを実装できる。

==モジュール==
===静的モジュール===
リスト追加

===動的モジュール（DSO）===
リスト追加

Apache HTTP Server

2026-04-27T00:06:32Z

Y: /* WordPress の xmlrpc攻撃の遮断 */

[[ファイル:apache.png|thumb|Apache|300px]]
[[ファイル:port.png|thumb|港の配送センター|300px]]

'''Apache HTTP Server''' とは手元のマシンを港 (配送センター) にするためのソフトウェア。C言語製。Apache を城に導入してインターネットに広く公開するとその城は「港 / 公開サーバ」になる。WWW の世界は膨大な数のWebマシンたちの膨大な量の働きによって支えられている。

ちなみに、「人気な港」になると日本中から注文リクエストが殺到することになるので、それを効率よくさばくためのチューニングが必要になったりする。高品質な Service を serve する Server/Servant になる。

==公式の説明書==
* [https://httpd.apache.org/docs/2.4/en/ Apacheドキュメント]

==注文ログ==
# cd /var/log/apache2
# tail -f access_log

数分見ているだけで本当に色々な注文がくる。そして正当な注文は少ない笑。

==セキュリティ==
* security2-module を入れる
* ServerTokens を Prod にして表示を「Apache」だけにする
* Options で -Indexes指定してフォルダ一覧を非表示
* 他マシンからのリソースの使い回し要求を拒否する
* Next.js を Apache でリバプロしてる場合、evasive 入れるとブラウザからの複数リクエストが Dos扱いになりデータが一部表示されなくなるのでブロックされるので入れない

===WordPress関係===
xmlrpc攻撃の遮断。めちゃくちゃ接続リクエストくるので /etc/apche2/apache2.conf に追加。

<Files "xmlrpc.php">
Require all denied
</Files>

==キャッシュ==
キャッシュを使えばサーバが全てのレスポンスに対応する必要がなくなる。つまり、サーバの負担が軽減する。キャッシュは Webサービスの主要な構成要素。

# 共有キャッシュ - 専用サーバなど
# プライベートキャッシュ - ブラウザ内など

キャッシュには上記２種類があり、サーバに比べていずれもクライアントに近い場所にあるので毎回サーバからダウンロードするよりもレスポンス速度が向上する。

コンテンツの更新頻度とのバランスを考えながら上手にキャッシュを使えば、高いパフォーマンスを実装できる。

==モジュール==
===静的モジュール===
リスト追加

===動的モジュール（DSO）===
リスト追加

Apache HTTP Server

2026-04-27T00:05:55Z

Y: /* セキュリティ */

[[ファイル:apache.png|thumb|Apache|300px]]
[[ファイル:port.png|thumb|港の配送センター|300px]]

'''Apache HTTP Server''' とは手元のマシンを港 (配送センター) にするためのソフトウェア。C言語製。Apache を城に導入してインターネットに広く公開するとその城は「港 / 公開サーバ」になる。WWW の世界は膨大な数のWebマシンたちの膨大な量の働きによって支えられている。

ちなみに、「人気な港」になると日本中から注文リクエストが殺到することになるので、それを効率よくさばくためのチューニングが必要になったりする。高品質な Service を serve する Server/Servant になる。

==公式の説明書==
* [https://httpd.apache.org/docs/2.4/en/ Apacheドキュメント]

==注文ログ==
# cd /var/log/apache2
# tail -f access_log

数分見ているだけで本当に色々な注文がくる。そして正当な注文は少ない笑。

==セキュリティ==
* security2-module を入れる
* ServerTokens を Prod にして表示を「Apache」だけにする
* Options で -Indexes指定してフォルダ一覧を非表示
* 他マシンからのリソースの使い回し要求を拒否する
* Next.js を Apache でリバプロしてる場合、evasive 入れるとブラウザからの複数リクエストが Dos扱いになりデータが一部表示されなくなるのでブロックされるので入れない

===WordPress の xmlrpc攻撃の遮断===
めちゃくちゃ接続リクエストくるので。/etc/apche2/apache2.conf に追加。

<Files "xmlrpc.php">
Require all denied
</Files>

==キャッシュ==
キャッシュを使えばサーバが全てのレスポンスに対応する必要がなくなる。つまり、サーバの負担が軽減する。キャッシュは Webサービスの主要な構成要素。

# 共有キャッシュ - 専用サーバなど
# プライベートキャッシュ - ブラウザ内など

キャッシュには上記２種類があり、サーバに比べていずれもクライアントに近い場所にあるので毎回サーバからダウンロードするよりもレスポンス速度が向上する。

コンテンツの更新頻度とのバランスを考えながら上手にキャッシュを使えば、高いパフォーマンスを実装できる。

==モジュール==
===静的モジュール===
リスト追加

===動的モジュール（DSO）===
リスト追加

Aランク・ボディ

2026-04-26T00:32:45Z

[[ファイル:cha hyun seung.jpg|thumb|フィジカル100|400px]]

自分の身体を「Aランク」にリコンポ（鍛え上げ）、維持するゲーム。 
せっかくだし人生で１度くらいは「Aランク」ボディーを手に入れて、維持してみる。

文武両道すぎる。2025/08/17

==基本的な考え方==
* 経過をシンプルで分かりやすくするために「定数で固定（変数を少なく）」する。生活スタイルや食事内容など
* Aランク・ボディーの実現と維持に最適化された１日スタイルを設計し、ただそれを繰り返す
* ３ヶ月スパンくらいで結果が目に見えてくる

==リコンポの基本戦略==
脂肪を落としつつ、筋肉をつける｢Body recomposition｣の基本戦略について。 
要は、以下が基本ルート💪

# 何よりも、筋トレ/ランの順番で運動量アップと脂肪燃焼
# 高タンパク食事（炭水化物、脂質も適量）で筋肉量アップ
# 食事カロリーはちょい下げ
# Uber運動で基礎運動と足筋も

＊リコンポの基本的な考え方は [https://www.youtube.com/watch?v=5m5cBdijz3g こちら] や [https://www.esquire.com/jp/menshealth/fitness/a63096475/how-to-lose-your-fat-and-gain-muscle/ こちら]

===1. 消費kcal ＞摂取kcal===
* 活動量より食事量を少し少なくする。つまり、活動量より 200〜300kcal くらい食事量を少なく。
* ただ、摂取タンパク質を減らすと筋肉量が減る。タンパク質は毎日コンスタントに摂取

===2. １日に摂取する栄養===
* タンパク質：100g/日（毎日摂取。実際に筋肥大が起こるのは休日なので）。鶏むね肉 or ササミ、どっちでもいい
* 脂質：全体の20~25%くらい（少なめ。ホルモン維持、関節のために必要）
* 炭水化物：残りkcalはここ（筋トレ日は普通に、それ以外は少なめ）
* トレ後30分以内に炭水化物（グリコーゲン）補充で筋肉分解を防ぐ
* １回の食事で摂取できるタンパク質は40g程度なので２回に分ける
* 鶏肉は比較的消化が速い (腸内滞在時間が短い) ので、牛肉よりも鶏肉を食べる

タンパク質は筋肉だけじゃなくて、酵素・ホルモン・免疫細胞の材料にもなるから、毎日一定量が大事。ちなみに「おにぎり1個＝筋肉のセーフティネット」みたいなもん。

===3. トレーニング===
# Uber運動：基礎代謝UP、ベアフットで足筋肉アップ
# 筋トレ：強度強めで週2,3回。先に筋トレしてから有酸素ラン。まずはグリコーゲンを消費するため
# 有酸素ラン：目的はリコンポなので心肺を追い込む必要はない。グリコーゲンが少ないと脂肪が燃焼されやすい

===4. 睡眠と回復===
* しっかり運動した日は睡眠の質が上がる。目覚めもスッキリ
* 睡眠不足は筋肉合成↓・脂肪蓄積↑

===5. フィードバック===
* 体重計ではなく鏡とウエスト周りのサイズ感で判断

==具体的なプラン==
毎日タンパク質100g は死守、炭水化物を日によって調整、ってのが王道。

===Uber運動だけの日===
炭水化物は抑えめ。脂肪燃焼モードに。

* 昼食：ロイホ・鉄板チキングリル単品 (タンパク質58g)
* 夕食：鶏むね肉200g (タンパク質44g)、豆腐サラダ、キムチ納豆１パック
* 軽食：ナッツ、ドライマンゴー、など
* 2,000kcal/日くらい

===トレーニングもする日===
運動前後に「炭水化物もふつうに摂る」と筋肉の低下を防げる。

* 昼食：ロイホ・鉄板チキングリル単品 (タンパク質58g)
* 筋トレ：筋肉が適度に壊れるまで（下記参照）
* 低負荷の有酸素ラン：20分
* 夕食：鶏むね肉200g (タンパク質44g)、低GI炭水化物、豆腐サラダ、キムチ納豆１パック
* 軽食：豆乳バナナ小松菜ジュース (夏は氷入り)、ナッツ、ドライマンゴー、など
* 2,500kcal/日くらい

===サボり日===
* いつもの感じで１.５食

==筋トレメニュー==
スケートエリアで。

* 腕立てインクライン：30回
* スター・クランチ：30回
* 片足スクワット：各10回
* 懸垂：20回
* パンチ・キック：20回
* プランク：2分

これを２周（サーキット形式）。 
キツくなったら間に有酸素運動（[https://melos.media/training/47334/ アクティブレスト]）挟む。

* 最後に：レッグレイズ：好きな回数

===トレーニング頻度===
* 毎日：Uber運動（ベースの有酸素＆足筋＆活動量アップ）
* 週３以上：Uber運動＋筋トレ/ランの日 → 筋肉痛が出るくらいしっかり追い込む
* 筋肉痛ひどい日：休養、Uber運動だけ。落ち着いたら再開

===筋肉痛7,8割回復で再開OK===
筋肉痛が完全に抜けるのを待つより、痛みが軽くなったら再刺激の方が筋肥大にも効率的だし長く続けやすい。 
筋肉痛は「筋線維に微細なダメージが入って炎症してる」状態なので、普通のケガとは違う。

* 筋肉痛MAX（動けないレベル10） → 組織ダメージ大きい → 休むべき
* 筋肉痛2,3割（ちょっと張ってる・重い感じ） → 血流を良くすると回復が早まる
* 軽いトレーニングや有酸素運動はむしろ「リカバリー効果」がある

らしい、、まぁやってみて様子見。

==ポイント==
* 筋トレ/ランが 2〜3回/週できれば十分効果出る。筋トレを高頻度で、を意識
* 主食鶏肉300g＋アルファでタンパク質100g/日を維持して筋肉を強く育てる
* 筋トレメニューは強度をアップしていく工夫（フォーム・回数・負荷追加）を少しずつ
* 今のプラン（高タンパク・自然食・運動ペース）を3か月守れば、見た目は確実に変わる

まずはこの生活（と、その結果のボディ）がベースラインとなる。 
まずは「Aランク・ボディ」ベースを作って、維持してみる。

Aランク・ボディ

2026-02-05T06:33:53Z

===LED制御===
電源オンを「緑」、ストレージ書き込みを「赤」に。

$ dtparam=act_led_trigger=default-on #green light on
$ dtparam=pwr_led_trigger=mmc0 #microSD for red

===基本構造===
{| class="wikitable" summary="FHSに定義された基本構造"
|-
!ディレクトリ
!説明
|-
|<code>/</code>
|root。ファイルシステム全体を見渡せる頂点の場所
|-
|<code>/bin</code>
|binaries。一般ユーザ、管理者が利用するコマンドを配置 (142)
|-
|<code>/sbin</code>
|sytem binaries。主にシステム管理者が利用するコマンドを配置。ただし場合によっては一般ユーザも利用可能（例：init、ip、mount）(159)
|-
|<code>/boot</code>
|システム起動時に必要なブートローダ関連のファイルや、カーネルイメージを配置 (26)
|-
|<code>/dev</code>
|device。システム起動時に接続されているデバイスがチェックされ、自動的に作成される。<code>/dev/null</code> など (19)
|-
|<code>/etc</code>
|etcetera。システムやアプリの設定ファイル格納庫。初期ベル研のUNIX実装文書では単に「その他 = etcetera」のためのディレクトリだった (162)
|-
|<code>/lib</code>
|library。<code>/bin/</code> や <code>/sbin/</code> などの基本アプリが利用する共有プログラムやモジュールの図書館 (23)
|-
|<code>/media</code>
|removable media。USB や DVD など外部ストレージの接続ポイント (0)
|-
|<code>/mnt</code>
|mount。外部ファイルシステムの一時的な接続ポイント (0)
|-
|<code>/opt</code>
|option。追加でインストールしたパッケージ(アプリ）を配置 (1)
|-
|<code>/proc</code>
|process。カーネル内部の情報にアクセスするための仮想ファイル (151)
|-
|<code>/run</code>
|実行時の可変データ (38)
|-
|<code>/tmp</code>
|temporary files。ファイルの一時的な置場。マシンを再起動すると内容が消える
|-
|<code>/usr</code>
|全ユーザが共有するデータを配置。ユーティリティ、ライブラリ、コマンドなど (8)
|-
|<code>/usr/bin</code>
|一般ユーザ、管理者が利用するコマンドを配置(734)
|-
|<code>/usr/sbin</code>
|システム管理者のみが実行できるコマンドを配置(117)
|-
|<code>/usr/lib</code>
|各種コマンドが利用するライブラリを配置 (51)
|-
|<code>/usr/include</code>
|標準includeファイル群 (153)
|-
|<code>/usr/src</code>
|source code。ソースコード（例：カーネルのソースコードとそのヘッダファイル群など）(0)
|-
|<code>/usr/share</code>
|shared。x86など、アーキテクチャに依存しない共有データ。manフォルダなどもここ。(96)
|-
|<code>/usr/games</code>
|なぜか必須のゲーム用ディレクトリ (0)
|-
|<code>/usr/local</code>
|個人で作成したコマンドなどを配置。通常、さらにサブディレクトリとして <code>bin/</code>、<code>lib/</code>、<code>share/</code> などを持つ (9)
|-
|<code>/var</code>
|variable。システム運用中にサイズが変化するファイルを配置（例：ログ、スプール、一時的電子メールファイルなど。別パーティションとすることもある）(12)
|-
|<code>/var/log</code>
|システムやアプリのログファイルを配置
|-
|<code>/var/lib</code>
|状態情報。プログラムの実行によって更新された永続性データなど。（例：データベース、パッケージングシステムのメタデータなど）
|-
|<code>/var/cache</code>
|アプリケーションのキャッシュデータ。時間のかかるI/Oや計算によって生成されたデータなど。従って再度生成することも可能なので、削除してもデータが失われるわけではない（時間は無駄となる可能性がある）
|-
|<code>/var/lock</code>
|ロックファイル群。使用中リソースを保持するファイル。
|-
|<code>/var/run</code>
|最近のブート以降の走行中システムに関する情報。（例：現在ログイン中のユーザー、走行中のデーモンなど。FHS3.0 では /var/run は /run に置き換えられる。システムは後方互換性のために <code>/var/run</code> を提供するか、<code>/var/run</code> から <code>/run</code> へのシンボリックリンクを提供しなければならない
|-
|<code>/var/spool</code>
|処理待ち状態のタスクのスプール。（例：プリントキュー、未読メールなど）
|-
|<code>/var/tmp</code>
|一時ファイル置場。<code>/tmp</code> と異なりリブートしても内容が失われることはない
|-
|}

MediaWiki:Sidebar

2026-02-05T04:38:51Z

MediaWiki:Sidebar

2026-02-05T04:38:06Z

RaspberryPi

2026-02-05T04:36:21Z

Y: /* LED制御 */

===LED制御===
電源オンを「緑」、ストレージ書き込みを「赤」に。

dtparam=act_led_trigger=default-on #green light on
dtparam=pwr_led_trigger=mmc0 #microSD for red

===基本構造===
{| class="wikitable" summary="FHSに定義された基本構造"
|-
!ディレクトリ
!説明
|-
|<code>/</code>
|root。ファイルシステム全体を見渡せる頂点の場所
|-
|<code>/bin</code>
|binaries。一般ユーザ、管理者が利用するコマンドを配置 (142)
|-
|<code>/sbin</code>
|sytem binaries。主にシステム管理者が利用するコマンドを配置。ただし場合によっては一般ユーザも利用可能（例：init、ip、mount）(159)
|-
|<code>/boot</code>
|システム起動時に必要なブートローダ関連のファイルや、カーネルイメージを配置 (26)
|-
|<code>/dev</code>
|device。システム起動時に接続されているデバイスがチェックされ、自動的に作成される。<code>/dev/null</code> など (19)
|-
|<code>/etc</code>
|etcetera。システムやアプリの設定ファイル格納庫。初期ベル研のUNIX実装文書では単に「その他 = etcetera」のためのディレクトリだった (162)
|-
|<code>/lib</code>
|library。<code>/bin/</code> や <code>/sbin/</code> などの基本アプリが利用する共有プログラムやモジュールの図書館 (23)
|-
|<code>/media</code>
|removable media。USB や DVD など外部ストレージの接続ポイント (0)
|-
|<code>/mnt</code>
|mount。外部ファイルシステムの一時的な接続ポイント (0)
|-
|<code>/opt</code>
|option。追加でインストールしたパッケージ(アプリ）を配置 (1)
|-
|<code>/proc</code>
|process。カーネル内部の情報にアクセスするための仮想ファイル (151)
|-
|<code>/run</code>
|実行時の可変データ (38)
|-
|<code>/tmp</code>
|temporary files。ファイルの一時的な置場。マシンを再起動すると内容が消える
|-
|<code>/usr</code>
|全ユーザが共有するデータを配置。ユーティリティ、ライブラリ、コマンドなど (8)
|-
|<code>/usr/bin</code>
|一般ユーザ、管理者が利用するコマンドを配置(734)
|-
|<code>/usr/sbin</code>
|システム管理者のみが実行できるコマンドを配置(117)
|-
|<code>/usr/lib</code>
|各種コマンドが利用するライブラリを配置 (51)
|-
|<code>/usr/include</code>
|標準includeファイル群 (153)
|-
|<code>/usr/src</code>
|source code。ソースコード（例：カーネルのソースコードとそのヘッダファイル群など）(0)
|-
|<code>/usr/share</code>
|shared。x86など、アーキテクチャに依存しない共有データ。manフォルダなどもここ。(96)
|-
|<code>/usr/games</code>
|なぜか必須のゲーム用ディレクトリ (0)
|-
|<code>/usr/local</code>
|個人で作成したコマンドなどを配置。通常、さらにサブディレクトリとして <code>bin/</code>、<code>lib/</code>、<code>share/</code> などを持つ (9)
|-
|<code>/var</code>
|variable。システム運用中にサイズが変化するファイルを配置（例：ログ、スプール、一時的電子メールファイルなど。別パーティションとすることもある）(12)
|-
|<code>/var/log</code>
|システムやアプリのログファイルを配置
|-
|<code>/var/lib</code>
|状態情報。プログラムの実行によって更新された永続性データなど。（例：データベース、パッケージングシステムのメタデータなど）
|-
|<code>/var/cache</code>
|アプリケーションのキャッシュデータ。時間のかかるI/Oや計算によって生成されたデータなど。従って再度生成することも可能なので、削除してもデータが失われるわけではない（時間は無駄となる可能性がある）
|-
|<code>/var/lock</code>
|ロックファイル群。使用中リソースを保持するファイル。
|-
|<code>/var/run</code>
|最近のブート以降の走行中システムに関する情報。（例：現在ログイン中のユーザー、走行中のデーモンなど。FHS3.0 では /var/run は /run に置き換えられる。システムは後方互換性のために <code>/var/run</code> を提供するか、<code>/var/run</code> から <code>/run</code> へのシンボリックリンクを提供しなければならない
|-
|<code>/var/spool</code>
|処理待ち状態のタスクのスプール。（例：プリントキュー、未読メールなど）
|-
|<code>/var/tmp</code>
|一時ファイル置場。<code>/tmp</code> と異なりリブートしても内容が失われることはない
|-
|}

MariaDB

2026-02-03T13:43:37Z

[[ファイル:mariadb-logo.jpeg|thumb|MariaDB|300px]]
[[ファイル:library.jpg|thumb|データ基地|300px]]

'''MariaDB''' とはデータ基地を管理するためのApp。C言語製。SQLで基地にあるデータを高速に参照/更新/計算したりできる。アプリは基本的にデータ基地と連携しながら動く。ゆえに、アプリの本質とはデータベース。

当然ながら、MariaDB の[https://mariadb.org/documentation/ 公式の説明書]、[https://mariadb.com/kb/en/training-tutorials/ 公式チュートリアル] は一通り読んでおく。[[MySQLリファレンス]] も参照。

==セットアップ==
# 設定ファイル etc/my.cnf のモード、所有者、システム変数を確認
# /var/lib/mysqlディレクトリの所有者を mysql に変更
# ローカル利用ならリモート接続を禁止
# 日本語入力のズレを解消

$ mysqladmin -u root -p status
$ ss -tan

SHOW VARIABLES LIKE 'char%';
$ vi /etc/my.cnf

[mysqld]
skip-networking
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

* character_set_system は MariaDB の内部システム用の設定だから、utf8mb3 のままでOK

==データベースの本質==
データベースの本質は「実世界のパラレルワールド」をマシンの中に創造すること。ゆえに、データベースとは人間の認識を反映する鏡だと言える。

実世界（やその状態）を「パラレルワールド」としてマシンの中に複製すると、遠隔マシンにバックアップしたり、自作アプリと連携させたり、AIと抱き合わせて情報分析したりと、色々なことができるようになる。

RDB の場合、主にリレーション（テーブル相互の関係性）という表現手法に沿って実世界（やその状態）を整理しつつパラレルワールド化していくことになる。ちなみに、他の表現手法には NoSQL や DIT などがある。

===実世界の「本質」を適切に表現===
データベースの活用とはつまり実世界データ構造のパラレルワールド化。ゆえに、実世界を適切に認識し、その本質的な状態を適切にデータベースにアップロードしていく必要がある。

しかし、実世界の本質的な状態とは流動的で常に変化していくもの。この性質をしっかりと踏まえ、将来を見越したデータベース設計をする必要がある。

ゆえに、データ構造パラレルワールド化の際には以下３点が特に大切。

# 実世界の状態や本質を適切に認識する能力
# 目的から逆算してデータを整理する能力
# その状態を適切に表現する能力

以上３点があれば、その人は適切にデータベースを設計できる。そのような人は自分の部屋と同様にデータたちのお部屋も綺麗に整理することができるはず。

===マシンパワーが大前提===
データを管理するだけなら別に紙やノートを使っても良いはず。わざわざマシンにデータ管理を任せるのだから「マシンにしかできない何か」を強く期待しているはず。つまり、マシンパワーの活用と目的の実現とのバランスをしっかり前提とした上でテーブル設計やチューニングすることが大切。

データベース設計においては特に、以下２点を強く意識すべき。

# マシンパワーの活用を大前提としたデータベース設計
# 目的から逆算した実世界データ構造のパラレルワールド化

==セキュリティ==
DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost');

リモートから root で MariaDB にログインできると危険なので削除。

===rootのパスワードリセット===
一旦MariaDBのプロセスを落としてからセーフモードで起動、パスワードを設定してMariaDBのプロセスを再度起動させてやるだけ。

# systemctl stop mariadb
# mysqld_safe --skip-grant-tables &
alter user 'root'@'localhost' identified by 'new_passwd';
# systemctl stop mariadb
# systemctl start mariadb

以上。できなかったら「flush privileges」してから。

==データベース設計==
Database normalization。データベースを正常な状態にしておく。

===要点リスト===
* そのテーブルの主人公は誰（なに）なのかを主キーで明確にする
* そのテーブルはどのような「状態」の述語なのかを明確にする
* 実世界において２つの事柄を同時に認識することはできない
* ゆえに認識の鏡であるテーブルにも２つの概念を混ぜてはいけない
* ２つの概念が混じっているように感じるならテーブルを分けるべき
* テーブルを分けた時は外部キーを利用して両テーブルの整合性を保証
* １つの変更が多数箇所の修正に結びつく場合もテーブルを分けられるかも
* カラムに定義する属性は実世界の「状態」を適切に表現しているべき
* 例えば、id と cat_no は違う。id は各要素のID、cat_no はカテゴリ番号
* でも外部キーを追加するには一意性制約があるので上記２つをまとめても良い
* 命名はすべて短くて適切で本質的な表現であるべき
* １つの「状態」を２度も記述するような冗長なカラム設計は避けるべき
* NULL を許すと世界が 3VL になってしまいアプリ設計が非常に複雑になる
* NULL を許すとそのテーブルはオプティマイザとの相性が悪くなる
* NULL を許すとそのテーブルはインデックスとも相性が悪くなる
* NULL が入る余地があるということは DB設計に問題があるかも
* NULL 発生を引き起こす「ありえないデータ」は将来、悩みのタネになるかも
* SQL にはそもそも順序という概念がないので手続き型ロジックの実装は高負荷
* ゆえに、手続き型のロジックに頼るのは最後の手段にする
* 空間や時系列を表現したいのであれば RDB はやめる

==チューニング==

扱うデータ量が１００万件程度なら、そもそもマシンに負担はかからないのでチューニングする必要はあまりない。しかし、日頃からチューニングを意識したSQLに慣れておくのは良いこと。

===捜索範囲は適切に限定する===
* データサイズが小さいとパフォーマンス問題は表面化しない。テストはビッグデータで
* WHERE句を利用すれば総なめ捜索は回避されるのでマシンリソースを無駄にしない
* SELECT int, name など必要なデータだけを取得すればマシンリソースを無駄にしない
* 捜索データ１億件など、膨大なデータを捜索する場合は利用列にインデックスを作成
* かつ、カーディナリティ（値の多様性）が高い列にのみインデックスを作成
* インデックスは更新の負担が大きいため無闇矢鱈に作成しない
* 実際に捜索プランを立てている裏方オプティマイザの働きやすさを意識する

===アプリ制作において===
* トランザクションを開いて閉じる処理を実装したアプリ開発をしてるとSleep増殖ロックかかる時がある
* SELECT * は使わない。必要なデータを明示して取得する
* データベースを変更しても大丈夫なようにデータアクセスロジックを汎用的にしておく
* Abort発生の可能性はゼロにならないので Abort発生に備えてエラー処理は必ず実装しておく
* 書き込まれるデータの整合性を担保するためにデータ変更はトランザクションを利用する

===スレッドプール機能を使う===
膨大な数のクライアントからの膨大な数の SQL を処理する場合、スレッドプール機能が役立つ。スレッドプール機能の設定はとても簡単で、稼働中でも動的に設定を変更できる。

# my.cnf
thread_poolmax_threads = 500
thread_pool_idle_timeout = 100000

mysql > show global status like 'threadpool%';