基本的な問題を正しく診断しました。クライアントマシンのmy.cnfでデフォルトのMySQLクライアント文字セットを変更できますが または.my.cnf 、これらのファイルはPHPでは使用されません。
PHPのMySQLi/MySQL拡張機能がどのように機能するかを考えると、これは理にかなっています。mysqlとは何の関係もありません。 クライアントプログラムであり、libmysqlを使用しているため、構成ファイルのファイルシステムをクロールしません。 直接。
libmysqlの実際のデフォルトの文字セットを変更するには、libmysqlを再構築する必要があります。これは（プリコンパイルされたMySQLバイナリを使用しているため）あなたが好む答えではないかもしれませんが、実際の答えです。デフォルトはコンパイル時に設定され、実行時にオーバーライドできます。
これを行いたくなく、set_charset（）を呼び出すのが面倒な場合は、MySQLiクラスを拡張し、mysqliの代わりにそのクラスを使用することをお勧めします。つまり：
class MyDB extends mysqli {
// (You could set defaults for the params here if you want
// i.e. $host = 'myserver', $dbname = 'myappsdb' etc.)
public function __construct($host = NULL, $username = NULL, $dbname = NULL, $port = NULL, $socket = NULL) {
parent::__construct($host, $username, $dbname, $port, $socket);
$this->set_charset("utf8");
}
}
通常、アプリケーションでは、とにかくある種のデータベース抽象化レイヤーがあるので、このレイヤーにmysqliの代わりにMyDBを使用させるか、このレイヤーをにすることができます。 MyDBを使用して、必要なメソッドを追加またはオーバーライドします（これは、単純なORMのないアプリで行いました）。
class MyDB extends mysqli {}として開始された場合でも、常に何らかのデータベース抽象化レイヤーを用意することをお勧めします。 そうすれば、小さな変更を加えるためにコードベース全体を検索/置換する必要がなくなるからです。
RE：回避策として説明しているように、これにより、クライアントの要求に関係なく、基本的にデータベースサーバー全体がUTF-8にハードコードされます。サーバーは、それぞれが独自の文字セットを持つ複数のデータベースを持つ代わりに、UTF-8でのみ機能し、クライアントが別の文字セットに接続する場合、データをサイレントにマングルする可能性があります。アプリケーションの構成の1つの側面（データベース文字セット）をアプリ/クライアントマシンから実際には属していないデータベースサーバーに効果的に移動したため、これは根本的に間違っています。
アプリケーションスタックのレイヤーについて考える場合、
[server] <=> [network] <=> [client libmysql] <=> [PHP binary] <=> [app]
そうすれば、このようなアプリ固有の構成の「正しい」場所は、スタックの他の場所ではなく、アプリ自体にあることがわかります。 PHPでデータベースの文字セットを指定する必要はないかもしれませんが、考えてみると、接続先のデータベース自体を指定している場所でもあるため、実際にはそれが属している場所です。これは接続パラメーターです。サーバー構成の問題ではありません。文字セットを他の場所にハードコーディングすると、アプリケーションが移植できなくなります。