【mysql】auto_incrementの値を確認、変更。からの、0(ゼロ)入れたり歯抜け直してみたり - tweeeetyのぶろぐ的めも
はじめに ありきたりなメモなのですが久しぶりの息抜きメモ。 mysqlのauto_incrementについて、 下記みたいなことがちょくちょくありますがその度に忘れてるのでメモ。 auto_incrementの値知るのどうやんだっけなー deleteしちゃったからauto_incrementの値変えなきゃなー deleteしすぎて歯抜けになりすぎたから連番揃えてauto_incrementの値も変えてキレイにしたいなー あじぇんだ auto_incrementの設定を確認する auto_increment値を確認する auto_increment値を更新する auto_increment使ってるテーブルの歯抜けの連番を整理する auto_increment属性のカラムに0(ZERO)入れるとどうなるか 4と5はauto_incrementそのものというよりは auto_incrementテ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.8 文字列関数および演算子
ASCII(str) 文字列 str の左端の文字の数値を返します。 str が空の文字列である場合は、0 を返します。 str が NULL である場合は NULL を返します。 ASCII() は、8 ビット文字の場合に動作します。 mysql> SELECT ASCII('2'); -> 50 mysql> SELECT ASCII(2); -> 50 mysql> SELECT ASCII('dx'); -> 100 ORD() 関数も参照してください。 BIN(N) N のバイナリ値の文字列表現を返します。N は longlong (BIGINT) 数字です。 これは、CONV(N,10,2) と同等です。 N が NULL である場合は NULL を返します。 mysql> SELECT BIN(12); -> '1100' BIT_LENGTH(str) 文字列 str の長
mysqlで文字コードをutf8にセットする - Qiita
mysqlの文字コードはチェックする場所が多いので原因を突き止めるのに毎回苦労します。 大きく二種類に分けられて、 クライアント側、サーバー側（mysqlサーバー）、及びそれらの接続の文字コード データベース/テーブル/カラムの文字コード です。 デフォルトをきちんと設定しておく そもそも作成したDBの文字コードが意図しない設定になっていたら、デフォルトの設定が間違っている可能性が高いので、再度同じ問題を起こさないためにも、設定見直し→DBをdrop→DBをcreateという順番で直しに行きます。 1も2もデフォルトの設定は下記を実行すればok。 +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+-----------
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
Puppet で MySQL 5.7.6 以降をセットアップするために mysqld --initialize-insecure を使う - おいちゃんと呼ばれています
MySQL 5.7 は 昨年10月に GA 出た し、そろそろ導入したいなと。 Puppet でインストール＆セットアップしようとしたら、MySQL の root ユーザーのパスワードまわりで手間取ったのでメモ。 （Puppet だけではなく Docker とか、とにかく自動でセットアップしようとしたら関係するはず） 環境は下記のとおり。 CentOS 7.2 Puppet 3.8.5 MySQL 5.7.13-1.el7 忙しい現代人のための 3行まとめ MySQL 5.7.4 から root@localhost に自動生成されたパスワードが割り当てられるようになったよ（ただしパスワードは ~/.mysql_secret に書かれていたので読み取れた） MySQL 5.7.6 から自動生成されたパスワードが ~/.mysql_secret に書かれなくなったよ（/var/log/mysq
Dockerの公式MySQLイメージの使い方を徹底的に解説するよ · DQNEO日記
DockerHubでは公式のMySQLイメージが無料で公開されています。 これを使えば簡単にDockerでMySQLサーバを起動することができます。データの永続化もできます。 https://hub.docker.com/_/mysql/ 2015年10月現在では下記３種類のバージョンが用意されています。 タグを指定することで任意のバージョンのイメージを取得できます。 5.5 5.6 5.7 (latest) イメージの取得方法 docker pull mysql これで最新の安定版を取得できます。 バージョンを明示的に取得したい場合はタグを使います。 docker pull mysql:5.7 (2015/10/25現在だと、mysql, mysql:latest, mysql:5.7, mysql:5.7.9はどれも同じイメージを指します。) これのDockerfileを見たい場合はこ
日々の覚書: MySQL 5.6以降でクライアントに "Warning: Using a password on the command line interface can be insecure." と言われるのを防ぐいくつかの方法
MySQL 5.6以降でクライアントに "Warning: Using a password on the command line interface can be insecure." と言われるのを防ぐいくつかの方法 MySQL 5.6以降では、同梱のクライアント(mysqlコマンドラインクライアント, mysqladmin, mysqldumpあたりがよくありそう)に-pオプションで直接パスワードを渡すと、 $ mysql56 -utest -ptest -e "SELECT current_user()" Warning: Using a password on the command line interface can be insecure. +----------------+ | current_user() | +----------------+ | test@lo
MacにMySQL5.7をインストール。開発用my.cnfも公開
Homebrew の MySQL が 5.7 になったので 5.6 からアップグレードしてみました。インストール時に実行したコマンドと、5.7 対応した my.cnf を公開します。 動作確認環境 MacBook Pro 2015 13 インチMac OS X El Capitan 目次 MySQL をインストール MySQL を起動する mysql_secure_installation コマンドを実行する my.cnf サンプル エラーログを確認しよう インストール後、MySQL を運用していく上で知っておくと良いコマンド MySQL をインストール Homebrew を最新版に更新 brew update コマンドで Homebrew を最新版に更新しておきます。 $ brew update インストールされる MySQL のバージョンを確認 brew info コマンドでインストー
MySQL 5.7の新機能完全リスト | Yakst
MySQL 5.7には150を超える新機能がある。 MySQLのマニュアルはとてもいいものだが、少し長すぎる。これは、新機能の箇条書きリストだ。それぞれの機能について1つずつまとめるように頑張ってある。なので、 InnoDBのネイティブパーティショニング については、InnoDBの項かパーティショニングの項のどちらかにだけ載っている。 MySQL 5.7.8 RC2はここからダウンロードできる それか、yumかaptのリポジトリーからもインストール可能だ。 レプリケーション関連 マルチソースレプリケーション(訳注: 1スレーブに複数マスターを設定可能になった) [ 1 ] オンラインでのGTIDの有効化 [ 1 2 3 ] 準同期レプリケーションの性能向上 [ 1 2 ] ロスレス準同期レプリケーション [ 1 2 ] 準同期レプリケーションでいくつのスレーブからACKが返ってくるまで待つ
MySQL 5.7の重要機能まとめ | Yakst
MySQL Performance Blogの翻訳。MySQL 5.7にはたくさんの改善や新機能が盛り込まれていますが、その中でも特に重要なものについてのまとめ。 ある日、Percona Supportの顧客とMySQL 5.7の新機能について議論する機会があったのですが、その後、重要な機能をまとめたリストがあったらいいんじゃないかと考えました。最新のMySQL 5.7.6 リリース予定版(RC)が、素晴らしい機能を詰め込んで公開されたばかり。これがMySQL 5.7の重要機能一覧です。 レプリケーション機能の拡充 MySQL 5.7の最重要機能の1つは、マルチソースレプリケーションでしょう。この機能では、スレーブに対して複数のマスタを指定でき、これまでのマスタが1台のみという制限がなくなります。同僚が書いたマルチソースレプリケーションについてのいいブログ記事(日本語訳)が役に立つはずです
MySQL 5.7にやられないためにおぼえておいてほしいこと
2015/10/03 phpcon 2015 updated at 2016/01/13 about default_password_lifetime's default will be 0Read less
Rails を utf8mb4 で動かす
絵文字などを格納できるようにするため、MySQL の encoding を utf8mb4 にすると、1文字が最大 4バイトになる。すると、primary key と unique key として使うカラムが、InnoDB の最大長 767バイトを超えるために、 ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes というエラーが発生する。 それを乗り越えるための手順は以下の通り。 1) まず、my.cnf に以下を追加して restart させる。 character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci innodb_file_per_table = 1 innodb_file_format = Barracu
migration_comments + annotate で MySQL のカラムコメントを管理する - kakakakakku blog
今まで MySQL のカラムにコメントを付ける習慣がなかったんだけど，いざ新メンバーとして既存コードを読んで理解する立場になってみると，ちゃんと書かれたコメントのおかげでスキーマを理解しやすかったし，メンバー間の認識相違も生まれないし，重要だなと実感している． 確かに「コメントを付けないと理解できないならきっとテーブル設計やカラム設計に欠陥があるのでは？」という意見もあると思うし，それは否定しないけど，キレイに設計したとしても，ドメイン依存したコードやマジックナンバーもあるわけで，コメントを付けることが大きなメリットを生む場面は絶対にある． Rails で試してみる 今はもう Rails を使ってないんだけど，Rails で MySQL のカラムにコメントって付けられるの？と思って調べてみたら，基本機能ではできなさそうだった． migration_comments Gem を使う migr
MySQL Casual Talks Vol.8 でMySQL 5.7とMariaDB 10.1の性能比較について発表しました - hiroi10のブログ
はじめに 遅くなりましたが11/20(金)に開催されたMySQL Casual Talks Vol.8で以下スライドで発表しました。その内容の補足とかを載せておきます。 MySQL5.7とMariaDB10.1の性能比較(簡易) from hiroi10 最近MariaDB 10.1がGAになり、MySQL 5.7がGAになり、MariaDBってどうなん？、とか聞かれる事が増えたためとりあえずベンチマークで性能比較してみよう、が発端でした。MariaDBの10系はMySQL 5.5をベースにしているということで正直あまり期待していなかったのですが、起動時のログを見るとInnoDBはPerconaのXtraDB5.6ベースだったのでPercona5.6と同じ傾向かなぁという想像で実施しましたが概ね同じ傾向となりました。 まず、私はMariaDB10系はまともに触ったことがなかったので変だなと
第10回 yum, rpmインストールにおけるMySQL 5.6とMySQL 5.7の違い | gihyo.jp
MySQL道普請便り 第10回yum, rpmインストールにおけるMySQL 5.6とMySQL 5.7の違い 第8回 MySQLのバージョン体系を知るの中で、yumでインストールしたMySQL 5.6をMySQL 5.7にアップグレードしました。今回はアップグレードではなく、MySQL 5.7を新規にyumでインストールする場合のMySQL 5.6との違いを説明したいと思います。 MySQLのインストール方法はいくつかありますが、yumリポジトリーを利用したインストールが好んで選ばれるケースは、おそらくChefのレシピやDockerfileに利用する際ではないでしょうか。筆者はサンドボックス環境にはDockerをよく利用していますが、イメージを作成する際には原則MySQL公式のyumリポジトリーを使うようにしています。 yumリポジトリーを使用したインストール MySQL開発元のOrac
MySQL 5.7 を CentOS 7 に yum インストールする手順 |
本稿では、データベースサーバー MySQL Community Server 5.7 を yum を利用して CentOS 7 にインストールする手順について解説します。 事前準備 CentOS 7 には mariaDB という MySQL 互換のデータベースサーバーがデフォルトでインストールされている場合がありますので、これからインストールする MySQL と競合を起こさないように削除しておきましょう。 つぎのコマンドのように mariaDB ライブラリとデータフォルダを削除しておきます。 # yum remove mariadb-libs # rm -rf /var/lib/mysql/ MySQL 公式 yum リポジトリの追加 CentOS 7 に yum で MySQL をインストールするためには、MySQL 公式の yum リポジトリを利用します。 まずは CentOS 7 に
WHERE .. IN (..)のリストの順番でソートするORDER BY FIELDの仕組み
MySQLには`WHERE col IN (..) ORDER BY FILED(col, ..)`という書き方でINに並べた順番にソートしなおせるという知見がある。 こんなテーブルがあって、 mysql56> SELECT * FROM t1; +-----+-------+ | num | val | +-----+-------+ | 1 | one | | 2 | two | | 3 | three | | 4 | four | | 5 | five | | 6 | six | | 7 | seven | | 8 | eight | | 9 | nine | | 10 | ten | +-----+-------+ 10 rows in set (0.00 sec) INにテキトーな値を並べてやっても、 mysql56> SELECT * FROM t1 WHERE num IN
MySQLのタイムゾーン - tmtms のメモ
YAPC::Asia 2015 のセッションで、MySQL のタイムゾーンの話が出ていましたが、以前タイムゾーン周りで少しはまったことがあったのを思い出したので書いてみます。 MySQLのデフォルトのタイムゾーンは mysqld 起動時のシステム設定です。TZ 環境変数の値か、変数が設定されていなければ /etc/localtime(Ubuntu の場合) です。 # TZ=Japan /usr/sbin/mysqld mysql> SHOW VARIABLES LIKE '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | JST | | time_zone | SYSTEM | +---------
MySQL Casual Talks vol.7に行ってきた
今回は後輩エンジニアである @hfm ことおっくんの社外勉強会登壇デビュー戦を応援に行くのが１つ大きな目的。 当日の様子はtogetterから伺えます。肝心の彼の発表ですが、TLから拾う限り やばい話キタ タイトル 地獄感 既につらい 地雷臭 4.0ハラスメント 怖すぎる ガチュアル ただただ、すごい と参加されていた皆様を恐怖のドン底に陥れるには十分な内容だったと感じます。スライドはこちら では実際はどんな感じで進めていたかというところで、スライドの最後やおっくんの後日エントリに先輩エンジニアへの謝辞はありましたが、手助け出来たのはほんの少しで、ほぼ一人で頑張ったというのが合っているかなあと思います。 検証や当日の手順などメンテ完遂までに試行錯誤した記録として、Issueはマイルストン内に大小ありつつも34 issues、1つのIssueに133コメントがついたものもありました、すごい。
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
