{"id":161781,"date":"2026-02-19T11:11:59","date_gmt":"2026-02-19T09:11:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/stabilnyj-vypusk-subd-mariadb-12-2"},"modified":"2026-02-19T11:11:59","modified_gmt":"2026-02-19T09:11:59","slug":"stabilnyj-vypusk-subd-mariadb-12-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/stabilnyj-vypusk-subd-mariadb-12-2","title":{"rendered":"Lanzamiento estable del SGBD MariaDB 12.2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Se ha publicado la versi\u00f3n de la base de datos MariaDB 12.2.2, que se marca como la primera versi\u00f3n estable de la rama 12.2. La rama MariaDB 12.2 se ha clasificado como lanzamientos intermedios (rolling), contin\u00faa el desarrollo gradual de funcionalidades y sustituye a la rama MariaDB 12.1. Al mismo tiempo, se ha publicado la versi\u00f3n MariaDB 12.3.1 con una nueva implementaci\u00f3n de binlog, que tiene el estado de candidato para lanzamientos de la futura rama LTS. La rama MariaDB 12.2 ser\u00e1 mantenida hasta que se forme la versi\u00f3n 12.3.2. <\/p>\n
El proyecto de Mar\u00edaDB desarrolla una bifurcaci\u00f3n de MySQL, que mantiene la compatibilidad y se diferencia por la integraci\u00f3n de motores de almacenamiento adicionales y capacidades ampliadas. El desarrollo de Mar\u00edaDB es supervisado por la organizaci\u00f3n independiente Fundaci\u00f3n Mar\u00edaDB, en conformidad con un proceso de desarrollo abierto y transparente, que no depende de fabricantes individuales. Mar\u00edaDB se distribuye en lugar de MySQL en muchas distribuciones de Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) y se ha implementado en grandes proyectos como Wikipedia, Google Cloud SQL y Nimbuzz. <\/p>\n
Entre los cambios en la rama MariaDB 12.2: <\/p>\n
\n
Se han implementado las funciones TO_NUMBER (convierte una cadena en n\u00famero) y TRUNC (recorta una fecha, por ejemplo, a la hora, el d\u00eda, el mes o el a\u00f1o) en modo de compatibilidad con la base de datos Oracle.\n
Al realizar operaciones de uni\u00f3n de tablas (JOIN), se ha optimizado teniendo en cuenta la unicidad de las filas en subconsultas con la expresi\u00f3n \u00abGROUP BY\u00bb para prever de manera m\u00e1s precisa el n\u00famero de filas resultantes (out_rows) y aplicar correctamente los \u00edndices.\n
Se han a\u00f1adido nuevas opciones de control del optimizador ROWID_FILTER\/NO_ROWID_FILTER y INDEX_MERGE\/NO_INDEX_MERGE, as\u00ed como la capacidad de especificar impl\u00edcitamente los nombres de bloques en las consultas (se pueden aplicar opciones de optimizaci\u00f3n a partes espec\u00edficas de las consultas, haciendo referencia a ellas por los nombres \u00abselect#N\u00bb, donde N es el n\u00famero de orden del bloque). Por ejemplo: \u00abselect \/*+ JOIN_ORDER(@select#2\" twenty,ten) *\/ \u2026\u00bb.\n
Se han levantado las restricciones sobre el nivel de anidamiento de estructuras en funciones para trabajar con JSON (se elimin\u00f3 el l\u00edmite JSON_DEPTH_LIMIT, que anteriormente ten\u00eda un valor de 32).\n
Se ha a\u00f1adido la tabla TRIGGERED_UPDATE_COLUMNS en el esquema INFORMATION_SCHEMA (INFORMATION_SCHEMA.TRIGGERED_UPDATE_COLUMNS), que muestra las columnas que se modifican al activarse un desencadenador.\n
En la tabla PARAMETERS en el esquema INFORMATION_SCHEMA se ha implementado la columna PARAMETER_DEFAULT, que contiene los valores predeterminados de los par\u00e1metros de los procedimientos almacenados.\n
Se ha implementado soporte experimental para la expresi\u00f3n \u00abCREATE GLOBAL TEMPORARY TABLE\u00bb para crear tablas temporales globales. Este tipo de tablas temporales se eliminan al finalizar la sesi\u00f3n y son visibles para todos los usuarios, pero contienen datos \u00fanicos para cada usuario.\n
Se ha propuesto en fase de prueba una mejorada compatibilidad de replicaci\u00f3n entre tablas con estructuras diferentes. <\/ul>\n