ハードディスクメンテナンス

ハードディスクの診断、物理フォーマット、静音化、Linux、サーバー、MySQLなどがメインだったのですが、その後広がり、カメラやハードウェアの投稿も増えてきました。 モバイルデバイスは、MacBookAir(13型)、iPad Air2、ポメラ DM100(キングジム)OLYMPUS STYLUS XZ-2など。 これらを使いながら、ブログを更新しています。

カテゴリ: データベース



phpMyAdminを使ってMySQLにアクセスしているなら気付かンカムォだが、TeraTermなどのテキストでアクセスすると、結果が「???」となり文字化けしているコトがある。

MySQL文字化け

phpMyAdminの「サーバの文字セット」はUTF-8になっており、

サーバの文字セット_phpMyAdmin

TeraTermの設定やフォントもUTF-8であるにもカカワラヅだ。

設定_TeraTerm

フォント_TeraTerm

MySQLで

show variables like '%character%' ;

とすると、「character_set_results」が「latin1」になっている。

character_set_results_MySQL

# character_set_results:クライアントへ送信する文字コード

なンで、

set character_set_results = utf8 ;

としてUTF-8にシテヤルと、正常に表示される。

妖虫_冥ゐ

カクニンすると、以下の通り、「character_set_results」が「utf8」に変更されたコトが分かる。

character_set_results=UTF-8

ダレがlatin(ラテン)=ガイジン邪、ドァヴォ!!

他の「latin1」も全部「utf8」に設シタラ/設楽ゑ〜ンかはシラン(SILANE)し、utf8とutf8mb4の違いは何かもシラン(SILANE)。

set character_set_client = utf8 ;
set character_set_connection = utf8 ;
set character_set_database = utf8 ;
set character_set_server = utf8 ;

exitでMySQLを抜けて、MySQLの再起動。

mysql.server restart

再起動すると、ムァタ「latin1」に戻ッてる(文字化け復活)、このヴァクァ詐加減wwwww

だが、phpMyAdminの「その他>変数」でカクニンすると、「latin1」は存在シナイ罠!

サーバ変数と設定値_phpMyAdmin

モ〜(MOW)、ワクェが分からナゐョwwwwwwwwwwwwwww

MySQLの設定ファイル(my.cnf)を探し出し(方法は後述)、

# Default Homebrew MySQL server config
[mysqld]
character-set-server=utf8
[client]
default-character-set=utf8
# Only allow connections from localhost
bind-address = 127.0.0.1

を追記して保存、MySQLを再起動。

MySQLで

show variables like '%character%' ;

で再確認。

utf8_MySQL

再起動してもutf8が残り、成功。

[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



以下のようなテーブルがあるとスル。

↓SELECT * from `test` ;
MySQLのIN_001

DISTINCTは重複除外なので、2つあるaaaは1つしか表示されない。

↓SELECT DISTINCT `vid` from `test` ;
MySQLのIN_002

コノ時、idやcontsは表示されない(しようがナゐ)。

重複除外ツッタッテ、ドレが除外され、ドレが残ったンかは分からん/若乱からヌェ。

さて、INは複数指定可能なので、vidがaaaかbbbのモノが選ばれる。

↓SELECT * from `test` WHERE `vid` IN ('aaa','bbb') ;
MySQLのIN_003

ナヌォで、INにSELECT DISTINCTを使い(サブクエリ)、SELECT *で全項目表示が可能だと思われるが、

↓SELECT * from `test` WHERE `vid` IN (SELECT DISTINCT `vid` from `test`) ;
MySQLのIN_004

重複除外しているハヅのid=5が表示される、コノ意味不明詐であるwwwww

ティヌァミに、

SELECT * from `test` WHERE `vid` IN (SELECT `vid` from `test`) ;

とシても、結果は同じでアル...

DISTINCTが無視される、隠蔽改竄虚偽捏造偽装!!!

DISTINCTは重複除外であるが、GROUP by(グループ化)でも書ける。

以下の2つは同じ結果を返す。

SELECT DISTINCT `vid` from `test` ;

SELECT `vid` from `test` GROUP by `vid` ;

,肋綵劼里茲Δidやcontsは表示されヅ(できない)、△魯哀襦璽弉修靴討い襯灰箸らも分かるように表示できない。

関連:DISTINCTの逆(重複を抽出するSQL文)

関連:[MySQL] ランキングなどで順位を取得する方法 [自己結合]

関連:[MySQL] idを詰める(連番を振り直す)方法

関連:163data.com.cnの拒否IPリストを自動生成(deny)

関連:Macでサーバー(Apache,PHP,MySQL,WordPress)を作る

関連:[Mac] PHPのバージョンが異なる問題 [HighSierra]

関連:Ubuntu 18.04.2 LTSの32ビット版

SQL 第2版 ゼロからはじめるデータベース操作
翔泳社 (2016-07-11)
売り上げランキング: 5,007

SQLアンチパターン
SQLアンチパターン
posted with amazlet at 19.08.05
Bill Karwin
オライリージャパン
売り上げランキング: 7,819


[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



2万円以下の激安サーバーを紹介しよう。

富士通 PRIMERGY MX130 S2

PRIMERGY MX130 S2

19,800円が、2,000円引きクーポン使用で17,800円!!

在庫僅少!

OSレスタイプだが、自分でLinux入れるから不要だしね。

CPUもメモリーもハードディスク(250GB)もDVD-ROMドライブも載っているから、あとはLinuxを焼いてインストールするだけ。

激安サーバーはタワー型が大半だが、どうしても邪魔になる。

そんな中、スリム型縦置き可能なサーバーはイイね。

見た目がNAS風のサーバーもあるよ。

HP ProLiant MicroServer Turion II NEO N5

HP ProLiant MicroServer Turion II NEO N5

16,980円が、1,000円引きクーポン使用で15,980円!!

こちらも在庫僅少!

こちらはCPU、メモリー、ハードディスク(500GB)はあるが、光学ドライブがないので用意するか、USBメモリーからインストールすればよい。

Linuxを入れてファイルサーバーにしてもヨシ、MySQLを入れてDBの学習用にしてもヨシ!

サーバーの管理は、ハードを含めた知識が必要であると、私は考えている。

それならば、やはり実機だ。



MySQL全機能バイブル ~現場で役立つAtoZ~
鈴木 啓修
技術評論社
売り上げランキング: 61,578


実践ハイパフォーマンスMySQL 第3版
Baron Schwartz Peter Zaitsev Vadim Tkachenko
オライリージャパン
売り上げランキング: 112,943


[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



データベースで重要なindexであるが、全てのfieldにindexを定義するのは、多くの場合は無駄である。

定義しても、それが使用されなければ意味がない。

indexを定義することは、fieldのコピーを作ることに近く、更新性能の低下を招く。

全てのfieldにindexを追加すれば、テーブルが2つあるのと同じだ。

書込が発生すると、両方に書き込まねばならない(更新も同様)。

indexが役立つか分からないのに、全てのfieldに対してindexを設定するのは無駄。

読取がメインの場合は、ないよりはマシだろうが...

indexを設定しても全く使わないだろうfieldは、それほど考えなくても分かるはずだ。

よく見るのが、主キーには既にindexがあるのに、それとは別にindexを定義しているパターン。

冗長で無駄である。

なお、SQLによっては、indexが役に立たない(使われない)場合もある。

姓名の姓が●は、紙の電話帳で探せる。

紙の電話帳には、姓の順で並んでいるからだ。

しかし、名が●の場合は、これが使えない。

全ての姓に対して、名が●である可能性があるからだ。

複合indexを姓(sei),名(mei)の順で設定しても、名でのSELECT時には役に立たない。

同様に、名を第一基準にするORDER BY時にも役に立たない。

SELECT * FROM `user` ORDER BY `mei`,`sei` ;

また、LIKEで'%●'と前に%を入れた場合(後方一致)も、全てに一致する可能性があるのでindexが役立たない。

'%●%'と挟んだ中間一致も同様。

演算しての比較なども、indexは役に立たない。

WHERE `price` * 1.08 > 1000 ;

のような場合。

indexにあるデータは`price`であって`price` * 1.08ではないからだ。

これは、両辺を1.08で割って

WHERE `price` > 1000/1.08 ;

とすると、indexが使用できるようになる。

否定形(<>)や、IS NULL、ORも、indexが利用できない。

但し、ORはINで書き換えると、indexを使用できるようになる。

EXPLAINで、設定したindexがpossible_keysに含まれており、keyで実際し使用されているか確認しておく。



以下のSQLアンチパターンはおすすめ。

悪例を提示して解説してある。

あー、これこれ、あるある!みたいなwwwww

問題なく動いているから、というSQLの書き方をしていると、レコードが増えると重くなったりしない?

あとのことを考えていないのね。

また、予想した結果がSELECTされているからOK!と判断したりしてない?

様々なレコードが増えてきた場合、予期しない結果を返してこない?

SQLアンチパターン
SQLアンチパターン
posted with amazlet at 14.06.29
Bill Karwin
オライリージャパン
売り上げランキング: 7,908


SQL中で型の変換を「意識せずに」してしまい、あれ?index使用してない?とかwww
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



あるサイトに対する、無駄なアクセスが多いのは分かっている。

放置していたのだが、この機会に、少し追ってみる。

アクセスログを取っており、DB(MySQL)に格納しているので、

SELECT * FROM `log` WHERE `date` = '2014-05-XX' ;

として、特定の1日分を抽出。

約7.2MB(非圧縮)のログをダウンロードし、解析開始。

■ PVが多杉

レコード数は、37,705件。

1PVが1レコードなので、PV=37,705となる。

コンテンツ的に、日に三万PVを出すようなサイトではないwww

■ トップページが大半

トップページへのPVは、37,705件中の35,426件。

つまり、PVの94%がトップページ。

だいたい、アクセスの大半がトップページというのは異常。

認証不要なサイトであり、どのページからも入れるので、普通は末端のページから検索エンジン経由で入ってくるはずだ。

■ 163data.com.cn

hostを見ていると、163data.com.cnが目立つので調べてみると、28,098件あった。

全体の75%wwwwwwwwww

さすがはSN。

IPアドレスを抽出し、重複を除去した上で、.htaccessのdenyにヴチ込む。

[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック

このページのトップヘ