Hay muchas formas de optimizar la estructura de la base de datos, hay dos tipos principales:
Una es usar procedimientos almacenados para reemplazar las declaraciones de consulta SQL de uso común, reduciendo el proceso de análisis y compilación de declaraciones SQL.
El otro es utilizar el método de la tabla de particiones en el sistema de gestión de bases de datos. El método de optimización que usa procedimientos almacenados tiene las ventajas de una velocidad de ejecución rápida, pero no es propicio para la depuración, no hay forma de usar el mecanismo de caché de la base de datos y otras deficiencias, por lo que en el caso de mayores requisitos de seguridad y rendimiento del sistema, se recomienda usar el método de tabla de partición. Sin embargo, debe tenerse en cuenta que no es necesario aumentar la eficiencia de la consulta a través de la tabla de particiones de la base de datos siempre que haya suficientes datos, pero solo debemos considerar si la tabla de particiones debe usarse cuando los datos están segmentados.
Beneficios de la partición:
1) Disponibilidad mejorada: si falla una partición de una tabla, los datos de la tabla en otras particiones todavía están disponibles;
2) Mantenimiento conveniente: si una partición de la tabla falla, los datos deben repararse, solo la partición puede repararse;
3) E / S equilibrada: puede asignar diferentes particiones al disco para equilibrar las E / S y mejorar el rendimiento de todo el sistema;
4) Mejorar el rendimiento de la consulta: para la consulta de objetos particionados, puede buscar solo las particiones que le interesan para mejorar la velocidad de recuperación.
Hay dos formas de particionar la tabla de base de datos, la partición de tabla horizontal y la partición de tabla vertical.
Partición horizontal: el objetivo es dividir una tabla en varias tablas. Cada tabla contiene el mismo número de columnas (campos de tabla), pero el número de registros (filas de datos) disminuirá. Por ejemplo, podemos dividir una tabla de base de datos que contiene 100 millones de filas de registros en 12 tablas pequeñas según el método de partición horizontal, y cada tabla pequeña representa los datos de enero a diciembre de este año. De esta manera, cualquier consulta que necesite consultar los datos de un mes específico solo necesita consultar la tabla del mes correspondiente, y evitar consultar los datos de todos los meses almacenados en una tabla grande. De acuerdo con la eficiencia de ejecución de las declaraciones SQL, no hay duda de que la eficiencia de las consultas de tablas pequeñas será mucho mayor que la eficiencia de las consultas de tablas grandes.
Particionamiento vertical: este método es opuesto al método de partición horizontal. La partición desde la dirección vertical divide una tabla original en varias tablas con menos columnas. En las aplicaciones diarias, se puede decir que la partición horizontal es el método de partición más utilizado.
1. Introducción a la tecnología departición La partición ORACLE es una tecnología para manejar tablas muy grandes, índices, etc. Al dividir tablas e índices grandes en varios bloques pequeños que se pueden administrar de acuerdo con las reglas de partición, se evita que cada tabla se administre como un objeto grande e independiente, proporcionando un rendimiento escalable para grandes cantidades de datos. La partición reduce el tiempo requerido para las operaciones de administración al asignar operaciones a unidades de almacenamiento más pequeñas, mejora el rendimiento a través del procesamiento paralelo mejorado y aumenta la disponibilidad al proteger las particiones de datos fallidos.
2. Plan de optimización del diseño de la partición de la base de datos
2.1 Determine qué tablas grandes deben particionarse:
Cuando se utiliza la tecnología de particionamiento, no todas las tablas de la base de datos están particionadas, pero solo para algunas tablas grandes con gran volumen de datos. De acuerdo con la definición de partición, se puede ver que la partición en realidad divide un segmento de datos grande en varios segmentos de datos pequeños de acuerdo con las reglas. Si el objeto de la tabla en sí es pequeño, se pierde el significado de la partición. Según la experiencia, solo las tablas con un volumen de datos superior a 10 millones deben particionarse.
SQL> seleccione propietario, nombre_tabla, número_cantos
de dba_tables
donde número_camas> 10000000
y particionado = 'NO';
Nota: Cuando utilice la instrucción anterior para contar tablas grandes que necesitan ser particionadas, primero debe recopilar estadísticas del sistema de base de datos. De lo contrario, los datos de num_rows son inexactos y el número de registros del objeto de tabla no se puede expresar correctamente.
2.2 Discuta la elección del tipo de partición y el campo de partición:
Este paso es muy importante. La elección del tipo de partición y el campo de partición afecta seriamente el rendimiento de acceso de la tabla de datos. Elegir el tipo de partición o el campo de partición incorrectos tendrá un mayor impacto negativo en el rendimiento de la base de datos que no particionar, así que asegúrese de discutir con el equipo del proyecto cuando decida el tipo de partición y el campo de partición, y conviértalo de acuerdo con las necesidades comerciales y la lógica comercial.
Según la experiencia, los pasos para seleccionar el tipo de partición:
1) Primero determine qué campo de la tabla se usa con más frecuencia en el predicado de la instrucción select, este campo se usará como campo de partición.
Debido a que el propósito de la partición es separar el segmento de datos de una tabla grande en varios segmentos de datos pequeños de acuerdo con las reglas, el índice también se separa en varios segmentos de índice pequeños. Durante el acceso a los datos, solo se necesita acceder a uno de los segmentos de índice pequeños de acuerdo con el índice, y el último acceso Uno de los segmentos de datos, lo que reduce la cantidad de datos a los que se debe acceder, para lograr el propósito de la optimización. Si el predicado en la instrucción select no incluye el campo de partición, debe acceder a todo el segmento de índice y finalmente acceder a todos los segmentos de datos pequeños para ubicar los datos a los que se debe acceder.
2) Según las características del campo de partición, determine el tipo de partición.
Si el campo tiene un orden claro, entonces la tabla es adecuada para la partición de rango. Por ejemplo: tiempo, si el campo no tiene una relación clara de orden de rango, tiene un valor único o varios valores, entonces la tabla es adecuada para la partición de listas. Por ejemplo: departamentos, sucursales, si este campo no tiene una relación de orden de rango claro ni un valor específico, sino un número de serie, la tabla es adecuada para la partición hash. Tales como: número de lote, número de serie.
2.3 Espacio de tabla de datos y espacio de tabla de índice
La primera regla para diseñar objetos de tabla y objetos de índice es separar tablas e índices. La tabla y el índice correspondiente se establecen en diferentes espacios de tabla, preferiblemente en diferentes discos. Esto puede evitar muchos conflictos de E / S que se producen durante la gestión de datos y la consulta.
En este esquema de optimización, crearemos un espacio de tabla correspondiente para cada partición, dejaremos que las particiones de tabla se almacenen en diferentes espacios de tabla, para lograr la separación del acceso a datos entre diferentes particiones. Al mismo tiempo, también se crea un espacio de tabla de partición de índice independiente para cada partición de índice.
3. Tipo de partición
1. Descripción detallada de la partición de rango
La partición de rango es dividir un rango de valores en una tabla de datos y decidir en qué partición almacenar los datos en función de un rango de valores. Como particionar por número de serie, particionar por tiempo, etc. Según el número de serie, por ejemplo, menos de 2000000 se coloca en la parte01, 2000000 ~ 4000000 se coloca en la parte02. . .
create table AAA
(
id number primary key,
indate date not null
)
partition by range(indate)
(
partition part_01 values less than(to_date('2006-01-01','yyyy-mm-dd'))tablespace space01,
partition part_02 values less than(to_date('2010-01-01','yyyy-mm-dd'))tablespace space02,
partition part_03 values less than(maxvalue)tablespace space03
);
space01\ space02\ space03为建立的三个表空间，相当于把建立的一个大的表分在了3个不同的表空间的分区上了。
二、Hash分区（散列分区）详细说明
散列分区为通过指定分区编号来均匀分布数据的一种分区类型，因为通过在I/O设备上进行散列分区，使得这些分区大小一致。也就是只命名分区名称，这样均匀进行数据分布。
三、复合分区详细说明
有时候我们需要根据范围分区后，每个分区内的数据再散列地分布在几个表空间中，这样我们就要使用复合分区。复合分区是先使用范围分区，然后在每个分区内再使用散列分区的一种分区方法。
partition by range(indate)subpartition by hash(id)
subpartitions 3 store in (space01, space02, space03)
(
partition part_01 values less than(to_date(’2006-01-01’,’yyyy-mm-dd’)),
partition part_02 values less than(to_date(’2010-01-01’,’yyyy-mm-dd’)),
partition part_03 values less than(maxvalue)
);
四、分区表操作
1、插入记录：insert into AAA values(1 ,sysdate);
2、查询分区表记录：select * from AAA partition(part_01);
3、更新分区表的记录：update AAA partition(part_01) t set indate=’’where id=1; 但是当更新的时候指定了分区，而根据查询的记录不在该分区中时，将不会更新数据
4、删除分区表记录：delete from AAA partition(part_02) t where id=4; 如果指定了分区，而条件中的数据又不在该分区中时，将不会删除任何数据。
5、增加一个分区：alter table AAA add partition part_04 values less than(to_date(’2012-01-01’,’yyyy-mm-dd’)) tablespace dinya_spa ce03; 增加一个分区的时候，增加的分区的条件必须大于现有分区的最大值，否则系统将提示ORA-14074 partition bound must collate higher than that of the last partition 错误。
6、合并一个分区：alter table AAA merge partitions part_01,part_02 into partition part_02; ,如果在合并的时候把合并后的分区定为part_01的时候，系统将提示ORA-14275 cannot reuse lower-bound partition as resulting partition 错误。
7、删除分区：alter table AAA drop partition part_01; 删除分区表的一个分区后，查询该表的数据时显示，该分区中的数据已全部丢失，所以执行删除分区动作时要慎重，确保先备份数据后再执行，或将分区合并。
五、建立索引
分区表和一般表一样可以建立索引，分区表可以创建局部索引和全局索引。当分区中出现许多事务并且要保证所有分区中的数据记录的唯一性时采用全局索引。
1. 局部索引分区的建立：create index idx_t on AAA(id)
local
(
partition idx_1 tablespace space01,
partition idx_2 tablespace space02,
partition idx_3 tablespace space03
);
2. 全局索引建立时global 子句允许指定索引的范围值，这个范围值为索引字段的范围值：create index idx_t on AAA(id)
global partition by range(id)
(
partition idx_1 values less than (1000) tablespace space01,
partition idx_2 values less than (10000) tablespace space02,
partition idx_3 values less than (maxvalue) tablespace space03
);
当然也可以不指定索引分区名直接对整个表建立索引:
create index idx_t on AAA(id);
数据切分可以是物理上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。
数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样做的目的其实也是很简单的。 举个例子说明，比如article表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100 个table呢，从article_001一直到article_100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。
综上，分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率
读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。
为什么要分库、分表、读写分？
单表的数据量限制，当单表数据量到一定条数之后数据库性能会显著下降。数据多了之后，对数据库的读、写就会很多。分库减少单台数据库的压力。接触过几个分库分表的系统，都是通过主键进行散列分裤分表的。这类数据比较特殊，主键就是唯一的获取该条信息的主要途径。比如：京东的订单、财付通的交易记录等。。。该类数据的用法，就是通过订单号、交易号来查询该笔订单、交易。
还有一类数据，比如用户信息，每个用户都有系统内部的一个userid，与userid对应的还有用户看到的登录名。那么如果分库分表的时候单纯通过userid进行散列分库，那么根据登录名来获取用户的信息，就无法知道该用户处于哪个数据库中。
或许有朋友会说，我们可以维护一个email----userid的映射关系，根据email先查询到userid，在根据userid的分库分表规则到对应库的对应表来获取用户的记录信息。这么做是可以的，但是这个映射关系的条数本身也是个瓶颈，原则上是没有减少单表内数据的条数，算是一个单点。并且要维护这个映射关系和用户信息的一致性（修改登录名、多登录名等其他特殊需求），最大一个原因，其实用户信息是一个读大于写的库，web2.0都是以用户为中心，所有信息都和用户信息相关联，所以对用户信息拆分还是有一定局限性的。
对于这类读大于写并且数据量增加不是很明显的数据库，推荐采用读写分离+缓存的模式，试想一下一个用户注册、修改用户信息、记录用户登录时间、记录用户登录IP、修改登录密码，这些是写操作。但是以上这些操作次数都是很小的，所以整个数据库的写压力是很小的。唯一一个比较大的就是记录用户登录时间、记录用户登录IP这类信息，只要把这些经常变动的信息排除在外，那么写操作可以忽略不计。所以读写分离首要解决的就是经常变化的数据的拆分，比如：用户登录时间、记录用户登录IP。这类信息可以单独独立出来，记录在持久化类的缓存中（可靠性要求并不高，登陆时间、IP丢了就丢了，下次来了就又来了）
以oracle为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操作，同步更新cache，每次读取先读cache在读DB。写库就一个，读库可以有多个，采用dataguard来负责主库和多个读库的数据同步。
，改善整个系统的性能。除此之外，在数据维护方面，分区技术也有很大的优势。在进行历史数据转储时，只需要将需要转储的数据分区export备份出来转储至磁带中。而不需要将整张表全部export备份出来。在历史数据清理时可以将历史数据所在的分区truncate或drop，而不影响表的其他数据，同时释放空间。
