En el desarrollo web, hay decisiones que marcan la diferencia entre un proyecto robusto y uno que da problemas. Una de las más críticas es cómo conectas tu aplicación PHP con la base de datos. Históricamente, las funciones mysql_* (como mysql_connect() o mysql_query()) fueron el estándar, pero hoy son una mala práctica que ya no tiene cabida. Pero, ¿por qué? ¿Qué tienen de malo si, para muchos, siguen “funcionando”?
Aquí es donde me gusta ser directo. No se trata solo de que funcionen, sino de cómo funcionan y qué implicaciones tiene eso para la seguridad, el rendimiento y la mantenibilidad de tu código. Yo prefiero mil veces soluciones que me den tranquilidad a largo plazo, y mysql_* definitivamente no lo hace.
El problema principal: Las funciones mysql_* están muertas y enterradas
Quizás la razón más simple y directa para no usar mysql_* es que ya no existen en las versiones modernas de PHP. Punto.
Si tu sitio sigue funcionando con ellas, ojo que probablemente estás corriendo PHP 5.6 o una versión anterior. Esto es un riesgo gigante.
Deprecación y fin de soporte: Una cronología crítica
- Las funciones
mysql_*fueron oficialmente deprecadas en PHP 5.5, lanzado en junio de 2013. Esto significó que los desarrolladores de PHP ya no las recomendaban y avisaban que desaparecerían. - Fueron eliminadas por completo en PHP 7.0, que llegó en diciembre de 2015. Desde PHP 7.0 en adelante, estas funciones simplemente no existen en el lenguaje.
¿Qué implica esto? Si estás usando una versión de PHP que aún soporta mysql_*, estás usando una versión que no recibe actualizaciones de seguridad. Esto te deja expuesto a vulnerabilidades y ataques. En mi caso, la seguridad es un tema que me tomo muy en serio, y no me la juego con versiones antiguas.
Los problemas técnicos de mysql_*: Más allá de la obsolescencia
Incluso si milagrosamente encontraras una forma segura de seguir usando PHP 5.x, las funciones mysql_* tienen deficiencias técnicas graves que las hacen inaceptables para cualquier proyecto nuevo y un dolor de cabeza en los antiguos.
Seguridad: ¡El mayor dolor de cabeza con SQL Injection!
Este es el punto más crítico para mí. Las funciones mysql_* no tienen soporte nativo para sentencias preparadas o consultas parametrizadas. Esto te obliga a “escapar” manualmente los datos de entrada del usuario usando mysql_real_escape_string().
El problema no es la función en sí, sino que la responsabilidad de usarla recae 100% en el desarrollador. Es fácil olvidarla, usarla mal, o que en algún punto del código se te pase por alto, abriendo una puerta gigante a los ataques de SQL Injection. De hecho, muchos de los sitios que he visto comprometidos tenían este tipo de vulnerabilidad.
Con las sentencias preparadas (que sí tienen mysqli y PDO), el motor de la base de datos distingue entre el código SQL y los datos, haciendo que la inyección sea prácticamente imposible si se usan correctamente. Es una forma mucho más limpia y menos propensa a errores de manejar la seguridad.
Ausencia de funcionalidades modernas y buenas prácticas
Más allá de la seguridad, mysql_* se quedó estancado en el pasado. No soporta:
- Interfaz orientada a objetos (OO): No tiene una API moderna. Tienes que manejar todo con funciones globales, lo que a mí no me convence para organizar un código limpio.
- Consultas no bloqueantes o asíncronas: Para aplicaciones de alto rendimiento, esto es clave. Con
mysql_*, te quedas esperando. - Procedimientos almacenados y múltiples sentencias: Si trabajas con bases de datos complejas, la falta de soporte para múltiples resultados o la ejecución de varios procedimientos es una limitación importante.
- Transacciones: La capacidad de agrupar operaciones de base de datos para que todas se confirmen o se reviertan si algo falla es fundamental para la integridad de los datos.
mysql_*no las soporta bien. - Nuevos métodos de autenticación de MySQL: MySQL 5.6 y 5.7 introdujeron nuevos métodos de autenticación de password que
mysql_*simplemente no entiende. - Soporte completo de codificación de caracteres y SSL: Si necesitas un control robusto sobre UTF-8 o conexiones cifradas,
mysql_*es muy limitado.
En resumen, estás renunciando a casi una década de mejoras y funcionalidades críticas en el ecosistema de PHP y MySQL. ¿Por qué querrías eso?
Un ejemplo de código que ya NO deberías usar:
error_reporting = E_ALL ^ E_DEPRECATED
$link = mysql_connect('localhost', 'user', 'pass');
mysql_select_db('testdb', $link);
mysql_set_charset('UTF-8', $link);Este bloque, aunque simple, representa una puerta trasera a problemas. mysql_connect y mysql_select_db son las primeras señales de alarma. Además, silenciar los errores de deprecación ciegamente como en la primera línea es una muy mala idea.
Entonces, ¿qué alternativas tenemos y cuál prefiero?
PHP nos ofrece dos alternativas sólidas y modernas para conectar a MySQL:
- MySQLi: Es la extensión “mejorada” de MySQL. Proporciona una interfaz orientada a objetos (además de una procedural si la prefieres) y soporta sentencias preparadas, transacciones y todas las características modernas de MySQL.
- PDO (PHP Data Objects): Es una capa de abstracción de bases de datos. Esto significa que puedes usar la misma API para conectar a diferentes tipos de bases de datos (MySQL, PostgreSQL, SQL Server, SQLite, etc.). También soporta sentencias preparadas y transacciones.
En mi experiencia, PDO es mi elección preferida. La razón principal es su flexibilidad. Si el día de mañana tienes que migrar tu base de datos de MySQL a PostgreSQL, con PDO el cambio es mucho más sencillo porque la mayor parte de tu código de acceso a datos sigue siendo el mismo. Con mysqli, te amarras más a MySQL.
Ambas son excelentes opciones. Lo importante es que uses alguna de ellas y te olvides por completo de mysql_*.
Ojo con las advertencias de deprecación (y cómo NO silenciarlas ciegamente)
Algunos desarrolladores, al encontrarse con errores de E_DEPRECATED, optan por silenciarlos con algo como error_reporting = E_ALL ^ E_DEPRECATED en su php.ini. Esto es un error grave. Si bien te quita el aviso de mysql_*, también oculta otras advertencias de deprecación que podrían estar indicando que otras partes de tu código están usando funcionalidades obsoletas y que necesitan atención.
Las advertencias de deprecación no son para molestarte, son señales de que tu código está en un camino sin salida y necesita ser actualizado. Ignorarlas es como ignorar la luz de “revisar motor” en tu auto.
La advertencia práctica: No dejes para mañana lo que puedes refactorizar hoy
El error más común que veo es la postergación. “Si funciona, no lo toques”, es una frase que se aplica mal en este contexto. Si tu proyecto aún usa funciones mysql_*, estás sentado sobre una bomba de tiempo. Tu código es inseguro, está atado a versiones antiguas de PHP, es difícil de mantener y te impide aprovechar las ventajas de las bases de datos modernas.
Mi recomendación es clara: prioriza la migración a mysqli o PDO. No es un lujo, es una necesidad urgente. Empieza por identificar las conexiones y las consultas, y planifica una refactorización incremental. No hay excusas válidas para seguir usando una tecnología que ya no solo está deprecada, sino que ha sido eliminada del lenguaje. Tu proyecto y tu tranquilidad te lo agradecerán.