もうデータベースとテーブルを分割しないで、試してみましょう

• NewSQLとは何ですか
• 従来の SQL の問題
  • サーバーハードウェアをアップグレードする
  • データシャーディング
• NoSQLの問題
  • アドバンテージ
  • 欠点がある
• 新しいSQLの機能
• NewSQL の主な機能
• 3種類のSQLの比較
• TiDB はどのようにして生まれたのですか?
• TiDB コミュニティ エディションとエンタープライズ エディション
• TIDB のコア機能
  • 水平方向の弾性膨張
  • 分散トランザクションのサポート
  • 金融グレードの高可用性
  • リアルタイムHTAP
  • クラウドネイティブな分散データベース
  • MySQLとの高い互換性
• OLTP&OLAP（独学）
  • OLTP (オンライン トランザクション処理)
  • OLAP (オンライン分析処理)
  • 機能の比較
  • 設計角度の違い
• TiDB の全体的なアーキテクチャ
• TiDBのメリット
• TiDB のコンポーネント
  • TiDBサーバー
  • PD（プレースメントドライバー）サーバー
  • TiKVサーバー
  • ティスパーク
  • ティフラッシュ
• TiKVの全体構成
  • 領域の分割と結合
  • 地域のスケジュール設定
  • 分散トランザクション
• 高可用性アーキテクチャ
  • TiDB 高可用性
  • PD の高可用性
  • TiKV 高可用性
• アプリケーションシナリオ
  • MySQL の断片化とマージ
  • MySQL を直接置き換える
  • データベース
  • 他のシステムのモジュールとして
• アプリケーション
• TiDB と MySQL の互換性の比較
• TiDB でサポートされていない MySql 機能
• 自動インクリメントID
• SELECT の制限
• 意見
• デフォルト設定の違い
  • キャラクターセット
  • 照合
  • 大文字と小文字を区別
  • パラメータの説明
  • タイムスタンプタイプフィールドの更新
  • パラメータの説明
  • 外部キーのサポート

TiDB は分散型 NewSQL データベースです。水平伸縮拡張、ACID トランザクション、標準 SQL、MySQL 構文、MySQL プロトコルをサポートし、強力なデータ整合性を備えた高可用性機能を備えており、OLTP シナリオだけでなく OLAP シナリオにも適したハイブリッド データベースです。

TiDB は、PingCAP によって独自に設計および開発されたオープンソースの分散リレーショナル データベースであり、オンライン トランザクション処理とオンライン分析処理 (HTAP) の両方をサポートする統合分散データベース製品です。レベルの高可用性、リアルタイム HTAP、クラウドネイティブ分散データベース、MySQL 5.7 プロトコルとの互換性、および MySQL エコロジー。

目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

什么是NewSQL

数据库发展至今已经有3代了：

1. SQL，传统关系型数据库，例如 MySQL
2. noSQL，例如 MongoDB,Redis
3. newSQL

传统SQL的问题

互联网在本世纪初开始迅速发展，互联网应用的用户规模、数据量都越来越大，并且要求7X24小时在线。

传统关系型数据库在这种环境下成为了瓶颈，通常有2种解决方法：

升级服务器硬件

虽然提升了性能，但总有天花板。

数据分片

使用分布式集群结构

对单点数据库进行数据分片，存放到由廉价机器组成的分布式的集群里，可扩展性更好了，但也带来了新的麻烦。

以前在一个库里的数据，现在跨了多个库，应用系统不能自己去多个库中操作，需要使用数据库分片中间件。

分片中间件做简单的数据操作时还好，但涉及到跨库join、跨库事务时就很头疼了，很多人干脆自己在业务层处理，复杂度较高。

NoSQL 的问题

后来 noSQL 出现了，放弃了传统SQL的强事务保证和关系模型，重点放在数据库的高可用性和可扩展性。

优点

• 高可用性和可扩展性，自动分区，轻松扩展
• 不保证强一致性，性能大幅提升
• 没有关系模型的限制，极其灵活

缺点

• 不保证强一致性，对于普通应用没问题，但还是有不少像金融一样的企业级应用有强一致性的需求。
• 不支持 SQL 语句，兼容性是个大问题，不同的 NoSQL 数据库都有自己的 api 操作数据，比较复杂。

NewSQL 特性

NewSQL 提供了与 noSQL 相同的可扩展性，而且仍基于关系模型，还保留了极其成熟的 SQL 作为查询语言，保证了ACID事务特性。

简单来讲，NewSQL 就是在传统关系型数据库上集成了 NoSQL 强大的可扩展性。

传统的SQL架构设计基因中是没有分布式的，而 NewSQL 生于云时代，天生就是分布式架构。

NewSQL の主な機能

• 複雑なクエリとビッグデータ分析のための SQL サポート。
• ACID トランザクションをサポートし、分離レベルをサポートします。
• 柔軟なスケーリング、容量の拡張と縮小は、ビジネス層に対して完全に透過的です。
• 高可用性と自動災害復旧。

3種類のSQLの比較

写真

TiDB はどのようにして生まれたのですか?

有名なオープンソース分散キャッシュ サービス Codis の作者であり、PingCAP の共同創設者兼 CTO である Huang Dongxu は、上級インフラストラクチャ エンジニアであり、分散ストレージ システムの設計と実装が得意であり、オープンソース愛好家の技術マスターです。今日、インターネットがこれほど繁栄しているにもかかわらず、データベースという曖昧で不確実な領域で、彼は依然として決定的な実践の方向性を見つけようとしています。

2012 年末まで、彼は Google が発表した 2 つの論文が自分の心の中で光を屈折させるプリズムのように見えました。これら 2 つの論文では、Google が社内で使用する大規模なリレーショナル データベースである F1/Spanner について説明します。F1/Spanner は、リレーショナル データベース、柔軟な拡張、グローバル分散の問題を解決し、本番環境で大規模に使用されています。「これが実現できれば、データ ストレージの分野にとって破壊的になるでしょう。」 Huang Dongxu 氏は完璧なソリューションの出現に興奮しており、これに基づいて PingCAP の TiDB が誕生しました。

TiDB コミュニティ エディションとエンタープライズ エディション

TiDBはコミュニティ版とエンタープライズ版に分かれており、エンタープライズ版ではサービスやセキュリティサポートを有償で提供します。

写真

TIDB のコア機能

水平方向の弾性膨張

TiDB の水平拡張は、新しいノードを追加するだけで実現でき、スループットやストレージをオンデマンドで拡張して、高い同時実行性と大量のデータのシナリオに簡単に対応できます。

TiDB のストレージとコンピューティングが分離されたアーキテクチャの設計のおかげで、コンピューティングとストレージは必要に応じてオンラインで拡張または縮小でき、拡張または縮小のプロセスはアプリケーションの運用および保守担当者にとって透過的です。

分散トランザクションのサポート

TiDB は標準 ACID トランザクションを 100% サポートします

金融グレードの高可用性

従来のマスター/スレーブ (MS) レプリケーション スキームと比較して、Raft ベースの多数決プロトコルは財務レベルの 100% データの強力な整合性保証を提供し、ほとんどのコピーを失うことなく自動障害回復 (自動フェイルオーバー) を手動で実行することなく実現できます。介入

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

实时 HTAP

TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP 无需传统繁琐的 ETL 过程

提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

云原生的分布式数据库

TiDB 是为云而设计的数据库，同 Kubernetes 深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力

高度兼容 MySQL

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。

提供丰富的数据迁移工具帮助应用便捷完成数据迁移，大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。

OLTP&OLAP(自学)

OLTP(联机事务处理)

OLTP(Online Transactional Processing) 即联机事务处理，OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，记录即时的增、删、改、查，比如在银行存取一笔款，就是一个事务交易

联机事务处理是事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。

OLAP(联机分析处理)

OLAP(Online Analytical Processing) 即联机分析处理，是数据仓库的核心部心，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。典型的应用就是复杂的动态报表系统

在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。

特性对比

OLTP和OLAP的特性对比

—OLTPOLAP リアルタイム OLTP には高いリアルタイム要件があります。OLTP データベースは、トランザクション アプリケーションが必要なデータのみを書き込めるように設計されており、単一のトランザクションをできるだけ早く処理できるようになります。OLAP のリアルタイム要件はそれほど高くありません。非常に多く、多くのアプリケーションはせいぜい毎日データを更新します ボリューム OLTP データのボリュームはそれほど大きくなく、通常は数十のレコードの読み取り/書き込みのみで、単純なトランザクションを処理します OLAP データのボリュームは大きいです (OLAP は動的クエリをサポートしているため、ユーザー必要なデータを取得する前に、大量のデータをカウントする必要がある場合がある 時系列分析などの既知の情報を使用するため、処理されるデータ量が多い ユーザーおよびシステム指向の OLTP は顧客指向であり、トランザクションとクエリの処理に使用される OLAP は市場指向であり、データ分析に使用されます データベース設計 OLTP はエンティティ リレーションシップ ER モデルとアプリケーション指向のデータベース設計を採用 スターまたはスノーフレーク スキーマを使用した OLAP とサブジェクト指向のデータベース設計

設計角度の違い

—OLTPOLAP ユーザーオペレーター、下位管理者、意思決定者、上級管理者、機能、日常業務、処理、分析、意思決定、主業務、追加、削除、変更、クエリ DB 設計、アプリケーション指向、トピック指向データ、現在、最新の詳細、二次元、離散履歴 単一、集約、多次元 統合、統合アクセス 読み取り/書き込み 数十のレコード 数百万のレコードの読み取り 作業単位 シンプルなトランザクション 複雑なクエリ 数千のユーザー 数百の DB サイズ 100MB- GB100GB-TB

TiDB の全体的なアーキテクチャ

TiDBのメリット

従来のスタンドアロン データベースと比較して、TiDB には次の利点があります。

• 優れたスケーラビリティを備えた純粋な分散アーキテクチャにより、柔軟な拡張と縮小をサポート
• SQL をサポートし、MySQL のネットワーク プロトコルを外部に公開し、ほとんどの MySQL 構文と互換性があり、ほとんどのシナリオで MySQL を直接置き換えることができます。
• 高可用性はデフォルトでサポートされており、少数のレプリカに障害が発生した場合、データベース自体が自動的にデータ修復とフェイルオーバーを実行でき、これはビジネスに対して透過的です。
• ACID トランザクションをサポートし、銀行振込などの強力な一貫性要件を持つ一部のシナリオに適しています。
• データ移行、同期、バックアップ、その他のシナリオをカバーする豊富なツール チェーン エコロジーを備えています。

TiDB のコンポーネント

TiDB の水平拡張機能と高可用性機能を深く理解するには、まず TiDB の全体的なアーキテクチャを理解する必要があります。TiDB クラスターには主に、TiDB サーバー、PD サーバー、TiKV サーバーの 3 つのコア コンポーネントが含まれており、さらに、ユーザーの複雑な OLAP ニーズを解決するための TiSpark コンポーネントもあります。

コア設計の観点から見ると、TiDB 分散データベースはアーキテクチャ全体を複数のモジュールに分割し、各モジュールが相互に通信して完全な TiDB システムを形成します。対応するアーキテクチャ図は次のとおりです。

写真

建築

TiDBサーバー

TiDB サーバーは、SQL リクエストの受信、SQL 関連ロジックの処理、PD による計算に必要なデータを保存するための TiKV アドレスの検索、TiKV と対話してデータを取得し、最終的に結果を返す責任を負います。TiDB サーバーはステートレスであり、データ自体は保存せず、コンピューティングのみを担当し、水平方向に無制限に拡張でき、負荷分散コンポーネント (LVS、HAProxy、または F5 など) を通じて外部に統一アクセス アドレスを提供できます。

PD (配置ドライバー) サーバー

Placement Driver (PD と呼ばれる) はクラスター全体の管理モジュールであり、次の 3 つの主なタスクがあります。

• 1 つは、クラスターのメタ情報 (キーがどの TiKV ノードに保存されているか) を保存することです。
• 2 つ目は、TiKV クラスターのスケジュールと負荷分散 (データ移行、Raft グループ リーダーの移行など) です。
• 3 つ目は、グローバルに一意の増分トランザクション ID を割り当てることです。

PD は、Raft プロトコルを通じてデータのセキュリティを確保します。Raft のリーダー サーバーはすべての操作の処理を担当し、残りの PD サーバーは高可用性を確保するためにのみ使用されます。奇数の PD ノードを展開することをお勧めします

TiKVサーバー

TiKV サーバーはデータの保存を担当し、外部から見ると、TiKV はトランザクションを提供する分散型 Key-Value ストレージ エンジンです。データを格納する基本単位はリージョンであり、各リージョンはキー範囲 (StartKey から EndKey までの左閉右開区間) のデータの格納を担当し、各 TiKV ノードは複数のリージョンを担当します。TiKV は、データの整合性と災害復旧を維持するために、レプリケーションに Raft プロトコルを使用します。レプリカはリージョン単位で管理され、異なるノード上の複数のリージョンは互いのレプリカであるRaftグループを形成します。複数の TiKV 間のデータの負荷分散は PD によってスケジュールされ、これもリージョン単位でスケジュールされます。

ティスパーク

TiSpark は、ユーザーの複雑な OLAP ニーズを解決する TiDB の主要コンポーネントとして、TiDB ストレージ レイヤー上で直接 Spark SQL を実行し、同時に TiKV 分散クラスターの利点を統合し、ビッグ データ コミュニティのエコロジーに統合します。これまでのところ、TiDB は 1 つのシステムで OLTP と OLAP の両方をサポートできるため、ユーザー データの同期の問題がなくなりました。

ティフラッシュ

TiFlash は特別なタイプのストレージ ノードです。通常の TiKV ノードとは異なり、TiFlash 内ではデータが列の形式で保存され、その主な機能は分析シナリオを高速化することです。

TiKVの全体構成

従来のフルノードバックアップ方式とは異なり、TiKV はキーの範囲に応じてデータをほぼ均等なスライス (以下、総称してリージョンと呼びます) に分割し、各スライスには複数のコピー (通常は 3 つ) があり、そのうちの 1 つはリーダー、読み取りおよび書き込みサービスを提供します。TiKV は、データと読み取りおよび書き込みの負荷が各 TiKV に均等に分散されるように、PD を通じてこれらのリージョンとレプリカをスケジュールします。この設計により、クラスター リソース全体が完全に活用され、マシンの数が増加するにつれて水平に拡張できます。

写真

領域の分割と結合

当某个 Region 的大小超过一定限制（默认是 144MB）后，TiKV 会将它分裂为两个或者更多个 Region，以保证各个 Region 的大小是大致接近的，这样更有利于 PD 进行调度决策。同样，当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时，TiKV 会将比较小的两个相邻 Region 合并为一个。

Region调度

Region 与副本之间通过 Raft 协议来维持数据一致性，任何写请求都只能在 Leader 上写入，并且需要写入多数副本后（默认配置为 3 副本，即所有请求必须至少写入两个副本成功）才会返回客户端写入成功。

当 PD 需要把某个 Region 的一个副本从一个 TiKV 节点调度到另一个上面时，PD 会先为这个 Raft Group 在目标节点上增加一个 Learner 副本（复制 Leader 的数据）。当这个 Learner 副本的进度大致追上 Leader 副本时，Leader 会将它变更为 Follower，之后再移除操作节点的 Follower 副本，这样就完成了 Region 副本的一次调度。

Leader 副本的调度原理也类似，不过需要在目标节点的 Learner 副本变为 Follower 副本后，再执行一次 Leader Transfer，让该 Follower 主动发起一次选举成为新 Leader，之后新 Leader 负责删除旧 Leader 这个副本。

分布式事务

TiKV 支持分布式事务，用户（或者 TiDB）可以一次性写入多个 key-value 而不必关心这些 key-value 是否处于同一个数据切片 (Region) 上，TiKV 通过两阶段提交保证了这些读写请求的 ACID 约束。

高可用架构

高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。

TiDB高可用

TiDB はステートレスであり、少なくとも 2 つのインスタンスをデプロイすることが推奨され、フロントエンドは負荷分散コンポーネントを通じて外部サービスを提供します。単一のインスタンスに障害が発生すると、このインスタンスで進行中のセッションに影響します。アプリケーションの観点から見ると、単一のリクエストの失敗が発生し、再接続後もサービスを引き続き取得できます。単一のインスタンスに障害が発生した場合は、再起動するか、新しいインスタンスをデプロイできます。

PD の高可用性

PD は、Raft プロトコルを通じてデータの一貫性を維持するクラスターです。単一のインスタンスに障害が発生した場合、インスタンスが Raft のリーダーでない場合、サービスはまったく影響を受けません。インスタンスが Raft のリーダーである場合、新しい Raft が生成されます。リーダーは再選され、サービスが自動的に回復されます。PD は選挙プロセス中は外部サービスを提供できません。この時間は約 3 秒です。少なくとも 3 つの PD インスタンスをデプロイすることをお勧めします。1 つのインスタンスに障害が発生した場合は、インスタンスを再起動するか、新しいインスタンスを追加します。

TiKV 高可用性

TiKV は、Raft プロトコルを通じてデータの一貫性を維持し (コピーの数は構成可能で、デフォルトで 3 つのコピーが保存されます)、ロード バランシングのスケジューリングに PD を使用するクラスターです。単一のノードに障害が発生すると、このノードに保存されているすべてのリージョンに影響します。リージョン内のリーダー ノードの場合、サービスは中断され、再選択を待ちますが、リージョン内のフォロワー ノードの場合、サービスは影響を受けません。TiKV ノードに障害が発生し、一定時間 (デフォルトでは 10 分) 以内に回復できない場合、PD はそのノード上のデータを他の TiKV ノードに移行します。

アプリケーションシナリオ

MySQL の断片化とマージ

写真

TiDB が適用される最初のタイプのシナリオは、MySQL のシャーディングとマージです。すでに MySQL を使用している企業では、サブデータベース、テーブル、シャード、ミドルウェアが一般的に使用されていますが、シャードの増加に伴い、クロスシャード クエリが大きな問題となります。TiDB はビジネス層で MySQL アクセス プロトコルと互換性があり、PingCAP はデータ同期ツール Syncer を作成し、Dongxu Huang の TiDB を MySQL スレーブとして使用し、メイン MySQL ライブラリの背後にある既存データベースのスレーブ ライブラリとして TiDB を接続できます。この層はデータを接続し、複雑なデータベース間、テーブル間、およびビジネス間のリアルタイム SQL クエリを直接実行できます。Huang Dongxu 氏は、「以前は、データベースには 1 つのマスターと複数のスレーブがありました。TiDB では、これを逆転させて、複数のマスターと 1 つのスレーブを実現できます。」と述べました。

MySQL を直接置き換える

写真

2 番目のタイプのシナリオは、MySQL を TiDB に直接置き換えることです。IT アーキテクチャが構築の開始時にサブデータベースとサブテーブルの問題を考慮せず、すべて MySQL を使用している場合、ビジネスの急速な成長に伴い、ますます大規模で同時実行性の高い OLTP シナリオが増えています。アーキテクチャの欠点を解決するには？

TiDB データベースでは、すべてのビジネス シナリオをデータベースとテーブルに分割する必要はなく、すべての分散作業はデータベース層によって実行されます。TiDB は MySQL プロトコルと互換性があるため、MySQL を直接置き換えることができ、基本的に箱から出してすぐに動作し、従来のデータベースとテーブルの分割方式によってもたらされる重い作業負荷や複雑なメンテナンスコストを心配する必要はありません。ユーザーインターフェイスにより、一般の技術者が効率的に保守管理を行うことができます。また、TiDBはNoSQLと同等の容量を有しており、データ量やアクセストラフィックが増加し続ける場合でも水平拡張によりシステムの業務支援能力を向上させることができ、応答遅延も安定しています。

データベース

写真

TiDB 自体は分散システムであり、3 番目の使用シナリオは TiDB をデータ ウェアハウスとして使用することです。TPC-H は、データ分析分野のテスト セットです。OLAP シナリオでの TiDB 2.0 のパフォーマンスが大幅に向上しました。データ ウェアハウスでのみ実行できる一部の複雑なクエリは、TiDB 2.0 で実行できます。基本的には10秒以内に制御されます。もちろん、OLAP の範囲は非常に広いため、TiDB の SQL も不確実です。このため、PingCAP は TiSpark をオープンソース化しました。TiSpark は Spark プラグインです。ユーザーは Spark SQL を直接使用して、TiKV でビッグ データ分析を行うことができます。リアルタイム。

他のシステムのモジュールとして

写真

TiDB はストレージとコンピューティングを分離する従来のプロジェクトであり、その基礎となる Key-Value レイヤーは HBase の代替として単独で使用でき、クロス行トランザクションをサポートします。TiDB は 2 つの API インターフェイスを外部に提供しており、1 つは行間トランザクションをサポートするために使用される ACID トランザクション API、もう 1 つは全体的なパフォーマンスの向上と引き換えに単一行トランザクションを実行できる Raw API ですが、クロス行トランザクション用の ACID は提供しません。 -行トランザクションのサポート。ユーザーは、自分のニーズに応じて 2 つの API から選択できます。たとえば、一部のユーザーは TiKV 上に Redis プロトコルを直接実装し、TiKV を大容量と低遅延の要件を持つ一部の Redis シナリオに置き換えています。

アプリケーション

写真

TiDB と MySQL の互換性の比較

• TiDB は、MySQL   トランスポート プロトコルとその構文のほとんどをサポートしています。これは、既存の MySQL コネクタとクライアントが引き続き動作することを意味します。ほとんどの場合、既存のアプリケーションはコードを変更せずに TiDB に移行できます。
• TiDB サーバーの現在正式にサポートされているバージョンはMySQL 5.7  です。ほとんどの MySQL 操作およびメンテナンス ツール (PHPMyAdmin、Navicat、MySQL Workbench など)、およびバックアップおよびリカバリ ツール (mysqldump、Mydumper/myloader など) を直接使用できます。
• ただし、一部の機能は分散環境ではうまく実装できないため、当面サポートされなかったり、MySQL とパフォーマンスが異なったりします。
• 一部の MySQL 構文は解析して TiDB に渡すことができますが、その後の処理は行われません。たとえば、Create Table ステートメントの Engine は解析されて無視されます。

TiDB でサポートされていない MySql 機能

• ストアド プロシージャと関数
• 引き金
• イベント
• カスタム関数
• 外部キー制約
• 一時テーブル
• フルテキスト/空間関数とインデックス
• ascii/latin1/binary/utf8/utf8mb4 以外の文字セット
• SYS schema
• MySQL 追踪优化器
• XML 函数
• X-Protocol
• Savepoints
• 列级权限
• XA 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开）
• CREATE TABLE tblName AS SELECT stmt 语法
• CHECK TABLE 语法
• CHECKSUM TABLE 语法
• GET_LOCK 和 RELEASE_LOCK 函数

自增ID

TiDB 的自增列仅保证唯一，也能保证在单个 TiDB server 中自增，但不保证多个 TiDB server 中自增，不保证自动分配的值的连续性，建议不要将缺省值和自定义值混用，若混用可能会收 Duplicated Error 的错误信息。

TiDB 可通过 tidb_allow_remove_auto_inc 系统变量开启或者关闭允许移除列的 AUTO_INCREMENT 属性。删除列属性的语法是：alter table modify 或 alter table change。

TiDB 不支持添加列的 AUTO_INCREMENT 属性，移除该属性后不可恢复。

SELECT 的限制

• 不支持 SELECT ... INTO @变量 语法。
• 不支持 SELECT ... GROUP BY ... WITH ROLLUP 语法。
• TiDB 中的 SELECT .. GROUP BY expr 的返回结果与 MySQL 5.7 并不一致。MySQL 5.7 的结果等价于 GROUP BY expr ORDER BY expr。而 TiDB 中该语法所返回的结果并不承诺任何顺序，与 MySQL 8.0 的行为一致。

视图

目前TiDB不支持 对视图进行UPDATE、INSERT、DELETE等写入操作 。

默认设置差异

字符集

• TiDB 默认：utf8mb4。
• MySQL 5.7 默认：latin1。
• MySQL 8.0 默认：utf8mb4。

排序规则

• TiDB 中 utf8mb4 字符集默认：utf8mb4_bin。
• MySQL 5.7 中 utf8mb4 字符集默认：utf8mb4_general_ci。
• MySQL 8.0 中 utf8mb4 字符集默认：utf8mb4_0900_ai_ci。

大小写敏感

关于lower_case_table_names的配置

TiDB 默认：2，且仅支持设置该值为 2。

MySQL 默认如下：

• Linux 系统中该值为 0

• Windows 系统中该值为 1

• macOS 系统中该值为 2

参数解释

• lower_case_table_names=0 表名存储为给定的大小和比较是区分大小写的
• lower_case_table_names = 1 表名存储在磁盘是小写的，但是比较的时候是不区分大小写
• lower_case_table_names=2 表名存储为给定的大小写但是比较的时候是小写的

timestamp类型字段更新

默认情况下，timestamp类型字段所在数据行被更新时，该字段会自动更新为当前时间，而参数explicit_defaults_for_timestamp控制这一种行为。

• TiDB 默认：ON，且仅支持设置该值为 ON。
• MySQL 5.7 默认：OFF。
• MySQL 8.0 默认：ON。

参数解释

• explicit_defaults_for_timestamp=off，数据行更新时，timestamp类型字段更新为当前时间
• explicit_defaults_for_timestamp=on，数据行更新时，timestamp类型字段不更新为当前时间。

外键支持

• TiDB 默认：OFF，且仅支持设置该值为 OFF。
• MySQL 5.7 默认：ON。