VARCHAR(X)やINT(X)の「X」は何を表しているのか - Qiita
はじめに 新人研修にてLaravelを使っている時のお話です。 テーブル設計を行う時にデータ型とサイズを決めなければなりませんでした。 その時に、例えば、INTの(X)のXは何を表しているのか正確に理解していなかったので、この機会に使用頻度の高いCHAR型やVARCHAR型などの文字列を格納するデータ型も含め、調べたいと思いました。 この記事を読み終えたあなたが適切にデータ型やサイズを決めることができることをこの記事の目標にしたいと思います。 ちなみにQiita初投稿です(なんか緊張する...)。 検証環境 macOS Catalina ver 10.15.7 Docker ver 20.10.5 docker-compose ver 1.29.0 Laravel ver 7.30.4 MySQL ver 8.20.3 内容 「ユニコード(Unicode)とは」 その前に、まず「文字コード
MySQLの照合順序 - Qiita
やってみた MySQLの照合順序、UTF-8の日本語で使える照合順序はいくつかあるけど、 実際にどんなマッチの仕方をするのかわからなかったので、ちょっとやってみた。 ちなみに、MySQLのUTF-8で日本語を扱う場合に使用可能な照合順序はしたの3つ。 utf8_bin utf8_general_ci utf8_unicode_ci 確認したかったのは、半角・全角、小文字・大文字がどんな感じでマッチするのかという事。 ながーいので、結果を utf8_bin キャラクターコードが完全に一致するもののみマッチする。 utf8_general_ci アルファベットの大文字・小文字は区別せずにマッチする。 ただし、区別しない文字は、半角は半角の大文字・小文字、全角は全角の大文字・小文字のみ。 半角小文字と全角小文字同士はマッチしない。 utf8_unicode_ci 下記がマッチする。 アルファベッ
【MySQL】インポート時間短縮のためのDBパラメータチューニング / 開発者向けブログ・イベント | GMO Developers
バイナリ互換性がないMySQLバージョン間（5.6→8.0）のDB移行が必要となり、DBを停止して、mysqldumpによるデータ移行を計画しました。その際にDBのダウンタイムをなるべく短くするため、インポートにかかる時間をパラメータチューニングによって短くできないか検証しました。 注意点 本記事の内容は、筆者の個人的な見解や認識に基づいて作成しているため、正確性、信頼性、完全性、最新性を保証するものではありません。 本記事は、2023/04/25 時点の情報をもとに作成しております。 最新の情報については、他の情報源と照らし合わせてご確認ください。 今回紹介するパラメータはインポート時に一時的に設定するパラメータと仮定しており、運用時は適さないパラメータもあります。 インポートが完了したら運用に適したパラメータへの変更をお願いします。 前提条件 インポートするデータ スキーマ毎にmysq
MySQL ですべてのテーブルを一括で OPTIMIZE する方法
今日も小ネタで、 MySQL で特定のデータベース内のすべてのテーブルを一括で OPTIMIZE する方法についてです。 確認時のバージョン MySQL 5.7 or 8.0 MySQL ですべてのテーブルを OPTIMIZE する方法 早速結論ですが、 mysqlcheck コマンドの --optimize オプションを使えば OK です: mysqlcheck --optimize --user="$MYSQL_USER" --password="$MYSQL_PASSWORD" "$MYSQL_DATABASE" --optimize | MySQL :: MySQL 8.0 Reference Manual :: 4.5.3 mysqlcheck — A Table Maintenance Program ちなみに、これはこの方法（ mysqlcheck --optimize ）に
MySQLの全テーブルを最適化(OPTIMIZE TABLE)する
パッケージソフトの開発会社や、業務系システムの開発会社にいた頃はデータベースといえばSQL ServerやOracleでした。 独立してからはオープンソース化の流れとライセンスの都合上でPostgreSQLを触る機会が多くなりましたが、MySQLを本格的に触り始めたのはわりと最近になります。MariaDBで興味を持ったのがきっかけですね。 Webサイトで使うデータベースを決めたら、まずメンテナンス用のスクリプトを組むのですが、はて、MySQLの場合はvacuumコマンド※がないのかな、と不思議に思いました。 PostgreSQLもバージョンアップによってvacuumしなくて良くなった！と聞いたときには、え、そんなバカな、と思いつつも一応調べてみるとauto vacuumできるようになったというだけでしたし。 MySQLのInnoDBは追記型データベースではないと言ってもメンテナンスコマンド
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！ - Qiita
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離
SQL Dialect is Not Configured (Phpstorm)
I am working on Google oauthorization2 and I encounter problem that SQL dialect is not configured That's why my query is not executing and data is going to table. I have listed below both of queries where I encounter problem. Tools: PhpStorm 8+ MySQL Localhost $user_exist = $mysqli->query("SELECT COUNT(google_id) as usercount FROM google_users WHERE google_id=$user_id")->fetch_object()->usercount;
mysqlのバックアップ(mysqldump)のロック問題 - SEEDS Creator's Blog
こんにちは、はらぐちです。 今回お話したいのは、mysqlのバックアップ方法についてのあれこれです。 バックアップ mysqldump mysqlのバックアップといえばmysqldumpです。 以下のような形で使います。 mysqldump -u root -p -x -A > my_dumpall.db これで全データベースのダンプができます。 特定のデータベースをダンプしたい場合は、以下のようにデータベース名を指定します。 mysqldump -u root -p -x データベース名 > dump.sql 定期的にバックアップを取りたい場合は、シェルスクリプトで以下のようなものを cronで実行してあげるといいでしょう。 二日間のバックアップを保持するスクリプト例です。 #!/bin/bash MPASS=パスワード mysqldump --defaults-extra-file=<
mysqlで文字コードをutf8にセットする - Qiita
mysqlの文字コードはチェックする場所が多いので原因を突き止めるのに毎回苦労します。 大きく二種類に分けられて、 クライアント側、サーバー側（mysqlサーバー）、及びそれらの接続の文字コード データベース/テーブル/カラムの文字コード です。 デフォルトをきちんと設定しておく そもそも作成したDBの文字コードが意図しない設定になっていたら、デフォルトの設定が間違っている可能性が高いので、再度同じ問題を起こさないためにも、設定見直し→DBをdrop→DBをcreateという順番で直しに行きます。 1も2もデフォルトの設定は下記を実行すればok。 +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+-----------
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと
— そーだい＠初代ALF (@soudai1025) 2015, 8月 24 とブーメラン投げて見事に刺さってるので今から記事書く。 両サイドにはかなり厳しい話もするが俺の本音を聴いておけ（関白宣言） まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。 なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。 むしろ実際に使ってみた際の違いをにフォーカスする。 1. SQLの違い 基本的にMySQLでやっていたことはPostgreSQL出来る。 しかし関数の挙動の違いは幾つかある。 例えば時間から曜日に該当する数字に変換した場合に MySQL → date_format(time,"%w") 0から始まり、日曜日に該当する PostgreSQL → to_char(time,'D') 1から始まり、日曜日に該当する など挙動に互換性
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
MySQLで指定されたカラム名を持つテーブルを検索する - Qiita
select table_name, column_name from information_schema.columns where column_name = '検索したいカラム名' and table_schema = '検索対象のデータベース名'; Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
JDBCドライバの取得(MySQL用) - データベース接続 - サーブレット入門
まずMySQLへの接続について試していきます。最初に行うことはMySQL用のJDBCドライバのインストールになります。 JDBCドライバとは、異なるデータベースに対するアクセスを行う際に、個々のデータベース毎にプログラムを書き換えなくていいように、データベースとJavaプログラムの間にあってデータベース毎の差を吸収してくれるものです。よってJDBCを使えばデータベースが異なってもJavaプログラムの方は変更を最小限にすることが可能です。逆にJDBCドライバはデータベース毎に用意する必要があります。 MySQL用のJDBCドライバはMySQLから提供されており「MySQL Connector/J」というものになります。現在MySQLは5系のものを使いますが、「MySQL Connector/J」も最新のバージョンは5.0となります。 ダウンロードは下記から行います。 http://dev.m
ER Master
<body> <span>このページはフレーム対応のブラウザでご覧ください。</span> </body>
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビューに関する情報を取得する
http://wannabe-note.com/1078
そーだい@初代ALF on Twitter: "コメントで /** * コードのメンテする君には申し訳ないことをした。 * 実行計画を見て驚いたと思う * MySQLはIN句にサブクエリを使うとINDEXが効かない * だけどこのまま進むしかなかったんだ、わかって欲しい **/ って書いた #1年後に自分が読むパターンの奴"
check if column exists before ALTER TABLE -- mysql