PolarDB:CREATE TABLE (AUTO mode)

Tipos de partición

Tipo Hash

En PolarDB-X existen dos tipos de particionamiento basado en hash: el particionamiento hash y el particionamiento key. Ambos forman parte de la sintaxis de particionamiento estándar de MySQL nativo. Para habilitar funciones flexibles de gestión de particiones —como la división, fusión y migración de particiones— y admitir la división de puntos críticos en claves de partición vectoriales, PolarDB-X redefine el enrutamiento del particionamiento hash y key. Aunque mantiene compatibilidad sintáctica con la sintaxis CREATE TABLE de MySQL, su implementación subyacente de partition routing difiere de la de MySQL. A continuación se describen las diferencias entre el particionamiento key y el particionamiento hash:

Ejemplo 1-1: Partición Key

CREATE TABLE key_tbl(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
PARTITION BY KEY(name, id)
PARTITIONS 8;

## This query triggers partition pruning and scans only a single partition.
SELECT id from key_tbl where name='Jack';

Si la primera partition column, name, provoca un data imbalance o un data hotspot, puede ejecutar una partition split mediante la siguiente partition column, como id. Para obtener más información, consulte Modify a table group level partition (AUTO mode).

Si una clave de partición vectorial con N columnas de partición usa sus primeras K columnas para el enrutamiento (1 ≤ K ≤ N), incluir condiciones sobre las columnas de partición de prefijo (las primeras K columnas) en la cláusula WHERE activa la eliminación de particiones.

Ejemplo 1-2: Particionamiento Hash

CREATE TABLE hash_tbl(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
partition by hash(id)
partitions 8;

CREATE TABLE hash_tbl_todays(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
PARTITION BY HASH(TO_DAYS(birthday))
PARTITIONS 8;

Actualmente, PolarDB-X admite las siguientes funciones de partición:

• YEAR

• MONTH

• DAYOFMONTH

• DAYOFWEEK

• DAYOFYEAR

• TO_DAYS

• TO_MONTHS

• TO_WEEKS

• TO_SECONDS

• UNIX_TIMESTAMP

• SUBSTR/SUBSTRING

Para las funciones SUBSTR/SUBSTRING, la clave de partición debe ser de tipo cadena; para todas las demás funciones de partición, debe ser de tipo de tiempo (como DATE, DATETIME o TIMESTAMP).

Ejemplo 1-3: Extensión del particionamiento Hash

CREATE TABLE hash_tbl2(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
PARTITION BY HASH(name, birthday)
PARTITIONS 8;

A diferencia del particionamiento key, el particionamiento hash usa una clave de partición vectorial en la que todas las columnas de partición participan en los cálculos de hash y de enrutamiento. Por lo tanto, para activar la eliminación de particiones, la cláusula WHERE de una consulta SQL debe especificar condiciones de igualdad para todas las columnas de partición. Por ejemplo, SQL1 puede activar la eliminación de particiones en la tabla hash_tbl2, pero SQL2 no:

##SQL1 (This query triggers partition pruning, scanning only a single partition)
SELECT id from hash_tbl2 where name='Jack' and birthday='1990-11-11';

##SQL2 (This query does not trigger partition pruning, resulting in a full partition scan)
SELECT id from hash_tbl2 where name='Jack';

Dado que el hash partitioning usa toda la partition key para calcular el hash value desde el inicio, en teoría distribuye los datos de manera más uniforme que el key partitioning con una vector partitioning key. Sin embargo, no admite la hotspot splitting, ya que no hay column s posteriores disponibles para dividir una partición saturada.

Límites

• Límites de tipos de datos

  • Tipos enteros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT y TINYINT UNSIGNED.

  • Tipos de tiempo: DATETIME, DATE y TIMESTAMP.

  • Tipos de cadena: CHAR y VARCHAR.

• Límites de sintaxis

  • Cuando se usa una función de partición con una clave de partición de una sola columna para una partición hash, la clave debe ser de tipo de tiempo.

  • Una clave de partición vectorial para una partición hash no admite funciones de partición ni división de puntos críticos.

  • De forma predeterminada, el número máximo de particiones es 8192.

  • De forma predeterminada, el número máximo de columnas de partición es 5.

Uniformidad de datos

• El algoritmo de hash consistente integrado para el particionamiento key y el particionamiento hash es MurmurHash3, un algoritmo de alto rendimiento con baja probabilidad de colisiones.

• Con MurmurHash3, la distribución de datos en el particionamiento key y el particionamiento hash suele equilibrarse solo cuando el número de valores distintos de la clave de partición (N) supera 3000. Cuanto mayor sea el valor de N, más equilibrada será la distribución de datos.

Tipo Range

En PolarDB-X existen dos tipos de particionamiento por rango: la partición Range y la partición Range Columns. Ambas forman parte de la sintaxis de particionamiento estándar de MySQL nativo. En la siguiente tabla se comparan estos dos tipos de partición.

Ejemplo 2-1: Particionamiento Range Columns

El particionamiento Range Columns admite una clave de partición vectorial, pero no una función de partición. Por ejemplo, para particionar una tabla por identificador de pedido y fecha de pedido, puede usar la siguiente sintaxis de CREATE TABLE:

CREATE TABLE orders(
 order_id int,
 order_time datetime not null)
PARTITION BY RANGE COLUMNS(order_id,order_time)
(
  PARTITION p1 VALUES LESS THAN (10000,'2021-01-01'),
  PARTITION p2 VALUES LESS THAN (20000,'2021-01-01'),
  PARTITION p3 VALUES LESS THAN (30000,'2021-01-01'),
  PARTITION p4 VALUES LESS THAN (40000,'2021-01-01'),
  PARTITION p5 VALUES LESS THAN (50000,'2021-01-01'),
  PARTITION p6 VALUES LESS THAN (MAXVALUE,MAXVALUE)
);

Ejemplo 2-2: Particionamiento Range

El particionamiento Range solo admite una clave de partición de una sola columna. Sin embargo, para una columna de partición de fecha y hora, puede usar funciones de partición como YEAR, TO_DAYS, TO_SECONDS o MONTH para convertir sus valores a enteros.

Por ejemplo, para crear particiones trimestrales en la columna order_time mediante particionamiento Range, use la siguiente sintaxis:

CREATE TABLE orders_todays(
 id int,
 order_time datetime not null)
PARTITION BY RANGE(to_days(order_time))
(
  PARTITION p1 VALUES LESS THAN (to_days('2021-01-01')),
  PARTITION p2 VALUES LESS THAN (to_days('2021-04-01')),
  PARTITION p3 VALUES LESS THAN (to_days('2021-07-01')),
  PARTITION p4 VALUES LESS THAN (to_days('2021-10-01')),
  PARTITION p5 VALUES LESS THAN (to_days('2022-01-01')),
  PARTITION p6 VALUES LESS THAN (MAXVALUE)
);

Límites

• Restricciones de tipos de datos

  • Tipos enteros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT y TINYINT UNSIGNED.

  • Tipos de fecha y hora: DATETIME y DATE.

  • Tipos de cadena: CHAR y VARCHAR.

• Restricciones de sintaxis

  • El particionamiento RANGE COLUMNS y el particionamiento RANGE no admiten el uso de un valor NULL como valor límite.

  • El particionamiento RANGE COLUMNS no admite el tipo de datos TIMESTAMP.

  • El particionamiento RANGE solo admite tipos enteros. Si la clave de partición usa el tipo TIMESTAMP, debe usar la función UNIX_TIMESTAMP para garantizar la coherencia de la zona horaria.

  • El particionamiento RANGE no admite la división de puntos críticos.

  • Durante las consultas, los valores NULL se tratan como el valor mínimo para el enrutamiento de particiones.

  • De forma predeterminada, el número máximo de particiones es 8192.

  • De forma predeterminada, el número máximo de columnas de partición es 5.

Tipo List

De forma similar al range type, PolarDB-X subdivide la list partitioning policy en dos tipos: list partitioning y list columns partitioning. Ambos tipos usan la sintaxis de particionamiento estándar de MySQL nativo. Además, PolarDB-X admite una default partition tanto para el list partitioning como para el list columns partitioning. En esta tabla se comparan ambos tipos:

Ejemplo 3-1: Particionamiento por List columns

list columns partitioning admite vector partition keys. Por ejemplo, list columns partitioning le permite particionar pedidos por país y ciudad. La table creation syntax es la siguiente:

CREATE TABLE orders_region(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST COLUMNS(country,city)
(
  PARTITION p1 VALUES IN (('China','Hangzhou'), ('China','Beijing')),
  PARTITION p2 VALUES IN (('United States','New York'),('United States','Chicago')),
  PARTITION p3 VALUES IN (('Russia','Moscow'))
);

Ejemplo 3-2: Particionamiento por list

Aunque list partitioning solo admite una single-column partition key, cuando se trata de una partition column de time-type, puede usar partition function expressions como YEAR, MONTH, DAYOFMONTH, TO_DAYS y TO_SECONDS para convertir sus valores a un integer type.

Por ejemplo, para crear una list partition basada en el año de la columna order_time, utilice la siguiente sintaxis de create table:

CREATE TABLE orders_years(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST(YEAR(order_time))
(
  PARTITION p1 VALUES IN (1990,1991,1992,1993,1994,1995,1996,1997,1998,1999),
  PARTITION p2 VALUES IN (2000,2001,2002,2003,2004,2005,2006,2007,2008,2009),
  PARTITION p3 VALUES IN (2010,2011,2012,2013,2014,2015,2016,2017,2018,2019)
);

Ejemplo 3-3: Particiones List columns y list con una partición predeterminada

PolarDB-X permite crear list columns partitions y list partitions que incluyen una default partition, hacia donde se enrutan los datos no definidos en las regular partitions.

CREATE TABLE orders_region(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST COLUMNS(country,city)
(
  PARTITION p1 VALUES IN (('China','Hangzhou'), ('China','Beijing')),
  PARTITION p2 VALUES IN (('United States','New York'),('United States','Chicago')),
  PARTITION p3 VALUES IN (('Russia','Moscow')),
  PARTITION pd VALUES IN (DEFAULT)
);

CREATE TABLE orders_years(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST(YEAR(order_time))
(
  PARTITION p1 VALUES IN (1990,1991,1992,1993,1994,1995,1996,1997,1998,1999),
  PARTITION p2 VALUES IN (2000,2001,2002,2003,2004,2005,2006,2007,2008,2009),
  PARTITION p3 VALUES IN (2010,2011,2012,2013,2014,2015,2016,2017,2018,2019),
  PARTITION pd VALUES IN (DEFAULT)
);

Límites

• Restricciones de tipo de datos

  • Tipos enteros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT y TINYINT UNSIGNED.

  • Tipos de tiempo: DATETIME y DATE.

  • Tipos de cadena: CHAR y VARCHAR.

• Restricciones de sintaxis

  • El particionamiento List Columns no admite el tipo de datos TIMESTAMP.

  • El particionamiento List solo admite tipos enteros.

  • Ni el particionamiento List Columns ni el particionamiento List admiten la división de puntos críticos.

  • De forma predeterminada, el número máximo de particiones es 8192.

  • De forma predeterminada, el número máximo de columnas de partición es 5.

Tipo CoHash

La política de particionamiento CoHash de PolarDB-X es exclusiva de PolarDB-X.

Requisitos de versión

Utilice la versión 5.4.18-17047709 o posterior.

Casos de uso

Esta estrategia de particionamiento se usa habitualmente en los siguientes escenarios de negocio:

Si una tabla tiene columnas correlacionadas, como c1 y c2, cuyos últimos cuatro caracteres siempre son idénticos, puede particionarla horizontalmente por ambas columnas. De este modo, las consultas SQL con una condición de igualdad en cualquiera de ellas se enrutan a una sola partición.

Por lo tanto, esta estrategia exige que los valores se mantengan consistentes entre varias columnas de partición dentro de la misma tabla particionada.

Ejemplo 4-1: Definir la ubicación conjunta con funciones de partición independientes

Suponga que su aplicación tiene una tabla orders donde las columnas order_id y buyer_id comparten los mismos seis últimos dígitos en cada fila. Para particionar esta tabla por dichos dígitos compartidos y garantizar que una consulta de igualdad sobre cualquiera de las dos columnas se enrute a la misma partición, utilice la siguiente sintaxis:

CREATE TABLE t_orders(
 id bigint not null auto_increment, 
 order_id bigint, 
 buyer_id bigint,
 order_time datetime not null,
 primary key(id)
) 
PARTITION BY CO_HASH(
 	RIGHT(`order_id`,6) /* The last 6 characters of order_id */,
 	RIGHT(`buyer_id`,6) /* The last 6 characters of buyer_id */
) 
PARTITIONS 8;

Ejemplo 4-2: Uso del azúcar sintáctico Range_Hash para migrar usuarios de 1.0 a 2.0

Para una migración de 1.0 a 2.0, considere una tabla orders fragmentada por base de datos y tabla mediante range_hash, definida así: DBPARTIITION BY RANGE_HASH(. Su tabla particionada correspondiente en la base de datos AUTO 2.0 se define de la siguiente manera:

CREATE TABLE orders(
 id bigint not null auto_increment, 
 buyer_id bigint,
 order_id bigint,
 ...
 primary key(id)
) 
PARTITION BY RANGE_HASH(order_id, buyer_Id,6) 
PARTITIONS 8;

PolarDB-X convierte automáticamente la sintaxis RANGE_HASH en una definición de partición CO_HASH. Por ejemplo, RANGE_HASH(order_id, buyer_Id, 6) se transforma en la siguiente definición CO_HASH:

CREATE TABLE orders(
 id bigint not null auto_increment, 
 buyer_id bigint,
 order_id bigint,
 ...
 primary key(id)
) 
PARTITION BY CO_HASH(
 	RIGHT(`order_id`,6) /* Uses the last 6 characters of order_id */,
 	RIGHT(`buyer_id`,6) /* Uses the last 6 characters of buyer_id */
) 
PARTITIONS 8;

Diferencias principales respecto al particionamiento hash/key

Dado que las estrategias de particionamiento CoHash y hash/key son similares, esta sección describe sus principales similitudes y diferencias de uso.

Consideraciones

• Su servicio debe mantener la relación coordinada entre los valores de las columnas de partición; PolarDB-X solo valida los resultados del enrutamiento. Cuando utiliza el particionamiento CO_HASH, PolarDB-X comprueba que todos los valores especificados de las columnas de partición de una fila se enruten al mismo fragmento. Sin embargo, no valida si los valores en sí cumplen con la relación coordinada. Esta responsabilidad recae en su servicio.

  Por ejemplo, suponga que su servicio exige que los últimos cuatro caracteres de las columnas c1 y c2 sean idénticos. Si un valor de c1, como 100234, y uno de c2, como 1320, se enrutan ambos al fragmento 0, PolarDB-X permite la operación insert (c1,c2) values (100234,1320) porque el enrutamiento es coherente. No obstante, esta operación infringe la regla del servicio, ya que los últimos cuatro caracteres de c1 (0234) y c2 (1320) no coinciden.

• Restricciones de DML al modificar columnas de partición Dado que el particionamiento CO_HASH correlaciona los valores de varias columnas de partición, PolarDB-X aplica las siguientes restricciones a las operaciones DML que modifican dichas columnas para evitar una distribución incorrecta de los datos:

  • En las instrucciones insert y replace, si los valores de distintas columnas de partición en una misma fila de la cláusula VALUES se resuelven en particiones diferentes, PolarDB-X rechaza la operación.

  • En las instrucciones update y upsert, debe modificar todas las columnas de partición de forma simultánea en la cláusula SET. Por ejemplo, si c1 y c2 son columnas de partición, debe usar una instrucción como UPDATE t1 SET c1='xx',c2='yy' WHERE id=1. Si los nuevos valores de distintas columnas de partición en una misma fila se resuelven en particiones diferentes, PolarDB-X rechaza la instrucción.

  • Cuando CO_HASH es la estrategia de particionamiento de un índice secundario global (GSI), PolarDB-X también rechaza cualquier operación DML sobre la tabla principal que provoque que los valores de distintas columnas de partición en una fila del GSI se resuelvan en particiones diferentes.

• Manejo de ceros a la izquierda en tipos enteros. Como las partition columns de una estrategia CO_HASH están correlacionadas, es común definirlas mediante una partition function como SUBSTR, LEFT o RIGHT. Este proceso puede generar ceros a la izquierda cuando se truncan enteros. Por ejemplo, suponga que su lógica de negocio exige que los últimos cuatro caracteres de c1 y c2 sean idénticos. Si c1 es 1000034, los últimos cuatro caracteres forman la string '0034'. Cuando la partition column es de un integer type, CO_HASH convierte automáticamente cualquier valor truncado al integer type de esa columna antes del routing. En consecuencia, CO_HASH convierte la string '0034' en el entero 34, calcula el hash value y enruta la fila. Este proceso gestiona los ceros a la izquierda de forma automática.

Límites de las funciones de partición

• RIGHT

• LEFT

• SUBSTR

Restricciones de tipo de datos

• Tipos enteros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT y TINYINT UNSIGNED

• Tipo de punto fijo: DECIMAL (con una escala de 0)

• Tipos de tiempo: No compatible

• Tipos de cadena: CHAR y VARCHAR

Restricciones de sintaxis

• No se pueden usar funciones de partición anidadas, como SUBSTR(SUBSTR(c1,-6),-4), en una columna de partición.

• Al utilizar el azúcar sintáctico RANGE_HASH, el parámetro de longitud no debe ser negativo.

• Todas las columnas de partición deben tener exactamente el mismo tipo de datos, incluidas las siguientes propiedades:

  • Juego de caracteres e intercalación

  • Longitud y precisión

• De forma predeterminada, el número máximo de particiones es 8192.

• De forma predeterminada, el número máximo de columnas de partición es 5.

/*
 * This example defines templated subpartitions by using a LIST-KEY composite strategy.
 * The table is first partitioned by LIST COLUMNS into three partitions.
 * Each partition is then subpartitioned by KEY into four subpartitions, resulting in a total of 12 physical partitions.
*/
CREATE TABLE sp_tbl_list_key_tp(
 id int, 
 country varchar(64),
 city varchar(64),
 order_time datetime not null,
 PRIMARY KEY(id)
)
PARTITION BY LIST COLUMNS(country,city) 
SUBPARTITION BY KEY(id) SUBPARTITIONS 4
(
  PARTITION p1 VALUES IN (('China','Hangzhou')),
  PARTITION p2 VALUES IN (('Russian','Moscow')),
  PARTITION pd VALUES IN (DEFAULT)
);

/*
 * This example uses a LIST-KEY composite strategy to define non-templated subpartitions.
 * The table is partitioned by LIST COLUMNS into three first-level partitions, each of which is then subpartitioned by KEY.
 * The first-level partitions have 2, 3, and 4 subpartitions, respectively.
 * This results in a total of 9 physical partitions (2 + 3 + 4).
*/
CREATE TABLE sp_tbl_list_key_ntp(
 id int, 
 country varchar(64),
 city varchar(64),
 order_time datetime not null,
 PRIMARY KEY(id)
)
PARTITION BY LIST COLUMNS(country,city) 
SUBPARTITION BY KEY(id)
(
  PARTITION p1 VALUES IN (('China','Hangzhou')) SUBPARTITIONS 2,
  PARTITION p2 VALUES IN (('Russia','Moscow')) SUBPARTITIONS 3,
  PARTITION pd VALUES IN (DEFAULT) SUBPARTITIONS 4
);

show create table tbl_varchar_cs;
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| TABLE          | CREATE TABLE                                                                                                                                                                                                          |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tbl_varchar_cs | CREATE TABLE `tbl_varchar_cs` (
    `a` varchar(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
    KEY `auto_shard_key_a` USING BTREE (`a`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8
PARTITION BY KEY(`a`)
PARTITIONS 64 |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)

explain select a from tbl_varchar_cs where a in ('AbcD');
+-------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                   |
+-------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_cs[p29]", sql="SELECT `a` FROM `tbl_varchar_cs` AS `tbl_varchar_cs` WHERE (`a` IN(?))") |
| HitCache:false                                                                                                          |
| Source:PLAN_CACHE                                                                                                       |
| TemplateId: 2c49c244                                                                                                    |
+-------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.11 sec)

explain select a from tbl_varchar_cs where a in ('abcd');
+-------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                   |
+-------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_cs[p11]", sql="SELECT `a` FROM `tbl_varchar_cs` AS `tbl_varchar_cs` WHERE (`a` IN(?))") |
| HitCache:true                                                                                                           |
| Source:PLAN_CACHE                                                                                                       |
| TemplateId: 2c49c244                                                                                                    |
+-------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.02 sec)

show create table tbl_varchar_ci;
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| TABLE          | CREATE TABLE                                                                                                                                                                      |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tbl_varchar_ci | CREATE TABLE `tbl_varchar_ci` (
    `a` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    KEY `auto_shard_key_a` USING BTREE (`a`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8
PARTITION BY KEY(`a`)
PARTITIONS 64 |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.06 sec)

explain select a from tbl_varchar_ci where a in ('AbcD');
+------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                  |
+------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_ci[p4]", sql="SELECT `a` FROM `tbl_varchar_ci` AS `tbl_varchar_ci` WHERE (`a` IN(?))") |
| HitCache:false                                                                                                         |
| Source:PLAN_CACHE                                                                                                      |
| TemplateId: 5c97178e                                                                                                   |
+------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.15 sec)

explain select a from tbl_varchar_ci where a in ('abcd');
+------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                  |
+------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_ci[p4]", sql="SELECT `a` FROM `tbl_varchar_ci` AS `tbl_varchar_ci` WHERE (`a` IN(?))") |
| HitCache:true                                                                                                          |
| Source:PLAN_CACHE                                                                                                      |
| TemplateId: 5c97178e                                                                                                   |
+------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.02 sec)