誰も教えてくれなかったMySQLの障害解析方法 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
ORDER BYとLIMIT, OFFSETの組み合わせには注意しよう｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
こんにちは、下條です。今日はSQLの軽い (しかし重要な) 話題について書いてみようと思います。 まずは以下の通りユニークでない col カラムを含む test テーブルを作成し、データを投入するSQLをご覧ください。 (MySQLでの例です。) create table test(id INT, col INT); insert into test values(1,1); insert into test values(2,1); insert into test values(10,1); insert into test values(3,1); そして、以下の2つのSQLを実行した場合、結果はどうなるでしょうか？ここで何が言いたいかが分かる方はこの先は読まなくてかまいません。 select * from test order by col limit 2 offset 0; se
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.7.7.5 SHOW COLUMNS ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
【Rails 5】utf8 -> utf8mb4 対応【mysql】 - Qiita
ActiveRecord::StatementInvalid: Mysql2::Error: Incorrect string value: '...' for column 'body' at row Mysql2::Error: Index column size too large. The maximum column size is 767 bytes. 「使えない文字が含まれてるよ」 「カラムのサイズがデカすぎる。767バイト以内にして」(合ってる・・？) rails5で開発中にこのエラーに出くわしたので、ここに対策を記載しておきます。 簡単に言うと上のエラー(1つめ)は絵文字が原因です。 絵文字を含んだ文字列をレコードに格納するには utf8からutf8mb4にテーブルの構造を変えなきゃならんのですが、 変えたら今度はバイト数の関係で下のエラー(2つめ)が発生します。 環境:
Rails 5 と MySQL 5.6 環境における utf8mb4 を扱う設定について - Qiita
mysql> use utf8mb4_sample_development; mysql> show variables like "chara%"; +--------------------------+------------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8mb4 | | character_set_filesyste
Dockerで立ち上げたMySQLにログインすると日本語が文字化け
TL;DR DockerでRailsとDBのコンテナを作成しWebアプリケーションを作成してたところ ブラウザ上では日本語が文字化けしないがdbコンテナの中に入ってmysqlにログインすると ???? に文字化けしている現象に遭遇した。 対象読者 or 前提条件 or 環境 DockerでMySQLコンテナを使用するマルチバイトなひと まずは調査 「Docker mysql 文字化け」でぐぐってみるとどうやら character_set_server=utf8 でないと発生するという記事が大量にヒットする。 Docker公式イメージのMySQLで文字コードを指定するのエントリを参考に過去にdocker-compose.ymlには対応を実装していたのでどうやらこれが問題ではなかった。 そもそもなにが原因で文字化けしてるのかがわからなかったので調べてみた。 $ mysql mysql> sta
rails - Mysql2::Error: Incorrect string value - そういうことだったんですね
次のエラーがでた場合。 Mysql2::Error: Incorrect string value: 原因を調べる おおむね、データベースの文字コードを確認する。 たいてい latin1 とかになっている。 $ mysql -uuser -p my_db mysql > show create table posts; CREATE TABLE `posts` ( `id` int(11) NOT NULL AUTO_INCREMENT, `title` varchar(255) DEFAULT NULL, `text` text, `created_at` datetime DEFAULT NULL, `updated_at` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAUL
Docker公式イメージのMySQLで文字コードを指定する - Qiita
version: '2' services: db: image: mysql:5.5 volumes: - data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: 'password' ports: - 3306 cache: image: memcached:1.4 ports: - 11211 rails: build: . command: bundle exec rails s -p 3000 -b '0.0.0.0' volumes: - .:/opt/rails ports: - "3000:3000" environment: RAILS_ENV: local DATABASE_URL: mysql2://root:password@db:3306 CACHE_SERVER: cache:11211 links: - db
MySQL :: MySQL 8.0 リファレンスマニュアル :: 9.7 コメント
#文字から行末まで。 -- シーケンスから行末まで。 MySQL では、-- (二重ダッシュ) のコメントスタイルは、2 番目のダッシュに少なくとも 1 つの空白または制御文字 (空白、タブ、改行など) を続ける必要があります。 セクション1.7.2.4「コメントの先頭としての「--」」で述べているように、この構文は標準 SQL のコメントの構文とは少し異なります。 C プログラミング言語のように、/* シーケンスから次の */ シーケンスまで。 この構文では、開始と終了のシーケンスは同じ行にある必要はないので、複数の行にわたってコメントを記すことができます。 次の例には、3 つのコメントスタイルがすべて示されています。 mysql> SELECT 1+1; # This comment continues to the end of line mysql> SELECT 1+1; --
ResultSetMetaDataのgetColumnLabel()とgetColumnName() - やねこやね
基本この2つのメソッドは同じ値を返す実装に各JDBCドライバはなってると思うのだけど（少ない私の経験上は今までそうだった）、mysql-connector 5.1.6で初めて違うパターンに巡り合いました。 「select xxx as yyy from zzz」 なんてSQLを書くとまあ、「yyy」が返ってくるのを期待するわけなんですが、mysql-connector 5.1.6では、getColumnLabel()だと「yyy」、getColumnName()だと「xxx」。 数年前MySQL使った時はこんな結果じゃなかった気がするなあ。 Java SE 6 から採用のJDBC4.0がらみの変更やもしれん（未確認）。Java SE 6のJavaDocのコメントを見る限りにおいてはこれが正しい動作なような気がするし。 まあDAOのライブラリでも自作しないと触らない部分ではあるとは思いますが
MariaDB×Windows インストール手順 | トライフィールズ
WindowsにMariaDBをインストールする手順についてお伝えいたします。 ファイルのダウンロード MariaDBのインストールファイルをダウンロードするために、次のサイトに移動します。 MariaDB.org – Supporting continuity and open collaboration 「Download」をクリックします。 「Download」をクリックします。 「Download 10.2.8 Stable Now!」をクリックします。ダウンロードの時期によっては、MariaDBのバージョンがここでお伝えしたものと異なる可能性が高いですが、基本的には安定板であるStableを選択した方が良いと思います。 32bit版のインストールファイルか64bit版のインストールファイルかを選択します。ご使用のOS状況に合わせてクリックしてください。 名前などを訊かれますが、ス
MySQLの照合順序 - Qiita
insert into `utf8_bin`(`str`, `num`) values ('a', null), ('ａ', null), ('A', null), ('Ａ', null), ('あ', null), ('ぁ', null), ('ア', null), ('ァ', null), ('高橋', null), ('髙橋', null), ('-', null), ('−', null), ('+', null), ('＋', null), ('0', null), ('０', null), ('1', null), ('１', null), (null, 0), (null, 1), (null, 9), (null, 100) ; insert into `utf8_general_ci`(`str`, `num`) select `str`, `num` from `utf
SQL実行計画の疑問解決には「とりあえずEXPLAIN」しよう | MySQLマイスターに学べ！ 即効クエリチューニング | Think IT（シンクイット）
EXPLAINステートメントとはEXPLAINは、SQLの実行計画に関する情報を取得するためのステートメントです。実行計画とは「どのインデックスを使って（あるいはインデックスを使わずにテーブルスキャンで）クエリーを処理するか」をMySQLが判断した結果のことです。「インデックスはちゃんと使われているだろうか」「インデックスでどこまでクエリーを効率的に処理できているだろうか」という疑問が湧いた時には、「とりあえずEXPLAINで」となりますよね。 EXPLAINのマニュアルはこちらに、EXPLAIN の出力結果のカラムの意味についてはこちらに記載があります。 EXPLAINの何を見るかたとえば、次のような重いクエリーがあったとしましょう。 mysql> SELECT COUNT(some_column) FROM some_table WHERE some_column = xxx; +--
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL スロークエリ改善 初心者向け - Qiita
MySQLでタイムゾーンを設定する - Qiita
MySQLでBLOB/TEXT型のカラムにはデフォルト値を設定できない | EasyRamble
MySQLでテーブルやカラムにコメントをつける - Qiita
Download MariaDB Products & Tools | MariaDB
MySQLのCSV出力が権限によって出来ない場合の対処法 - Qiita
