MySQL Database Training in Pune with Placement

What a relational database actually is, established before any query is written. Tables, rows, columns and the relational model as a way of removing duplication rather than a filing metaphor; where a database earns its place over a spreadsheet or a file; and how a client, the MySQL server and a storage engine divide the work between them.

MySQL 8.4 LTS is installed on Linux, macOS, Windows and Docker, and the three interfaces used for the rest of the course are set up together — the `mysql` command-line client, MySQL Workbench, and DBeaver — so a student can move between them without losing their place. The week closes on server configuration basics: `my.cnf`, character sets, and why `utf8mb4` is the only correct choice in 2026.

The statements that make up most working days. `SELECT` with every clause in the order the server evaluates them — `FROM`, `WHERE`, `GROUP BY`, `HAVING`, `ORDER BY`, `LIMIT` — taught in evaluation order rather than in writing order, because that is what explains why an alias works in `ORDER BY` and fails in `WHERE`.

Aggregate functions, `DISTINCT`, `CASE` expressions and `NULL` handling follow, with `NULL` given proper time: three-valued logic quietly produces wrong results in reports, and `COALESCE`, `IFNULL` and `IS NULL` are the fix. `INSERT`, `UPDATE`, `DELETE` and the DDL statements close the week, along with the habit of running a `SELECT` before every `UPDATE`.

Choosing the right column type, which is a decision that is expensive to reverse and is asked about in almost every database interview. Integer widths and signedness, `DECIMAL` versus `FLOAT` for money (and why the second one loses rupees), `CHAR` versus `VARCHAR` versus `TEXT`, and the date and time family including `TIMESTAMP` versus `DATETIME` and how each behaves across time zones.

Constraints are then treated as the database enforcing what the application forgot: primary keys, foreign keys with the full set of `ON DELETE` and `ON UPDATE` actions, `UNIQUE`, `CHECK` (genuinely enforced since 8.0), `NOT NULL` and defaults. Generated columns, `ENUM` and `SET`, and the auto-increment behaviour that surprises people after a rollback close the module.

Combining tables, which is where SQL stops being a reporting language and starts being a modelling one. `INNER`, `LEFT`, `RIGHT`, `CROSS` and self joins are drawn before they are written, and the two classic mistakes are made deliberately in class: the accidental cartesian product, and the `LEFT JOIN` silently turned into an inner join by a `WHERE` clause on the right-hand table.

Subqueries follow in all three positions — scalar, `IN` list and derived table — with the correlated and uncorrelated distinction made concrete through execution cost. Anti-joins with `NOT EXISTS`, semi-joins, `UNION` and `UNION ALL`, and the multi-table `UPDATE` and `DELETE` forms complete the module.

The 8.0 features that closed the gap with PostgreSQL and that most working developers still do not use. Common table expressions turn a nested three-level subquery into something a colleague can read, and recursive CTEs walk org charts, category trees and bill-of-materials structures without application-side loops.

Window functions are taught as the tool for the problems that used to require a self-join: running totals, per-group ranking, month-on-month change with `LAG` and `LEAD`, moving averages over a frame, and top-N-per-group. The module ends on native JSON — the document type, the path operators, `JSON_TABLE` for reading JSON as rows, and an honest rule for when a JSON column is the right design and when it is a normalised table avoiding its responsibilities.

Designing a schema that survives its second year. Entity-relationship modelling from a written requirement, then normal forms taught as the reasoning behind them rather than as definitions to recite — first, second, third and Boyce-Codd, each introduced by the update anomaly it removes. Denormalisation follows as a deliberate, measured performance decision with a stated cost.

The second half is schema evolution, which is where production systems are actually damaged. Migration tooling (Flyway, Liquibase, and the migration layers inside Django, Rails, Laravel and Spring), expand-and-contract as the pattern that lets a column be renamed without downtime, online DDL and `ALGORITHM=INSTANT` in 8.0, and the rule that a column is never dropped in the same release that stops using it.

Why the same query is fast on one table and slow on another. InnoDB's clustered index means rows are physically stored in primary-key order, and that single fact explains the cost of a random UUID primary key, the size of every secondary index, and what a secondary-index lookup actually does.

Index design is then built up deliberately: B-tree structure, the leftmost-prefix rule that decides whether a composite index is used at all, column ordering driven by selectivity and by the query's `WHERE` and `ORDER BY` shape, covering indexes that avoid the row lookup entirely, and prefix indexes on long strings. Full-text and multi-valued indexes, the cost of over-indexing on write throughput, and finding unused indexes close the module.

Reading what the optimiser decided instead of guessing. `EXPLAIN` and `EXPLAIN ANALYZE` line by line — the access-type ladder from `const` and `eq_ref` through `ref` and `range` down to a full `ALL` scan, the `key` and `rows` columns, and the `Extra` field where `Using filesort` and `Using temporary` announce the real problem.

The work then becomes diagnostic. The slow query log and `performance_schema` are used to find which query to fix first, on a dataset of over ten million rows so that the difference is measurable rather than theoretical. Common rewrites are practised — sargable predicates, avoiding functions on indexed columns, keyset pagination instead of a large `OFFSET`, and fixing the ORM N+1 pattern that produces a thousand queries where one would do.

Correctness under concurrency, the topic that separates a developer who has read about ACID from one who has debugged a deadlock at 2 a.m. Transactions, commit and rollback, savepoints, and the four isolation levels demonstrated against each other in two live sessions so that dirty reads, non-repeatable reads and phantoms are observed rather than described.

InnoDB's locking model is then opened up: row locks, gap and next-key locks, `SELECT ... FOR UPDATE` and `FOR SHARE`, and why `REPEATABLE READ` — MySQL's default — behaves differently from PostgreSQL's. Deadlocks are produced deliberately, read from `SHOW ENGINE INNODB STATUS`, and then designed out through consistent lock ordering and short transactions.

Server-side logic, taught with an honest account of when it is right. Stored procedure and function syntax, parameters, variables, control flow, cursors, error handlers and `SIGNAL`, then triggers for `BEFORE` and `AFTER` events at row level, and the scheduled event for recurring work.

The judgement matters as much as the syntax. Legacy Pune systems in BFSI and ERP carry substantial procedural logic and a developer joining one must be able to read and modify it; new systems generally put business rules in application code, where they can be unit-tested and reviewed. Both positions are argued, with the specific cases where a trigger or procedure genuinely wins — audit capture, data integrity that must hold across every client, and set-based bulk work.

Connecting MySQL to the code that uses it. Drivers and connection handling across the stacks Pune teams run — JDBC with Spring Boot and Hibernate, Python with SQLAlchemy and Django, Node.js with Prisma and mysql2, PHP with PDO — and connection pooling explained through what happens when the pool is exhausted under load.

Parameterised statements are treated as non-negotiable, with SQL injection demonstrated against a deliberately vulnerable endpoint and then closed. Credentials move to environment variables and a secret store; transactions are managed at the service boundary rather than per statement; and the whole of this course's work is kept in Git with branches, pull requests, a README and a documented schema, because the portfolio is what a hiring panel actually opens.

Locking the server down to what each caller genuinely needs. Account creation and the host part of a MySQL user that catches people out, the privilege hierarchy from global down to column level, roles in 8.0, and least privilege applied to a real application account rather than the `root` connection string that so many projects ship with.

Transport and storage security follow: TLS for client connections, `caching_sha2_password` as the 8.0 default, encryption at rest for tablespaces, and column-level protection for personal data. The module closes on the compliance shape Indian teams now work inside — India's DPDP Act and GDPR where clients are European — covering PII inventory, retention, the audit log, and deletion requests that a schema must be able to honour.

A backup nobody has restored is not a backup. Logical backups with `mysqldump` and `mysqlpump`, physical backups with Percona XtraBackup while the server stays online, and the binary log as the record that makes point-in-time recovery possible.

Every student then performs a real restore under exercise conditions: drop a table, recover the database to the second before the mistake, and verify the row counts. Backup strategy is designed rather than assumed — full and incremental schedules, retention, offsite copies, encryption, and the recovery point and recovery time objectives that decide all of it. The module closes on the failure modes that ruin restores: a backup that was never tested, a binary log that had been purged, and a dump taken without `--single-transaction`.

Running MySQL on more than one machine. Asynchronous source-replica replication built from scratch in class, GTID-based positioning that makes failover clean, semi-synchronous replication and what it does and does not guarantee, replica lag and how it produces stale reads in an application that assumed otherwise, and read-write splitting.

Group Replication and InnoDB Cluster provide the automated-failover story, with ProxySQL or MySQL Router in front. The module ends on managed cloud MySQL, which is how most new Pune workloads are deployed — Amazon RDS and Aurora MySQL, Azure Database for MySQL Flexible Server, and Cloud SQL — comparing what the provider takes over, what it costs, and which of the skills from this course still matter when it does.

The capstone runs the whole course through one system: a schema modelled from a written brief, loaded with millions of rows, queried through reports built on CTEs and window functions, tuned against measured `EXPLAIN` output, wrapped in transactions that behave under concurrency, secured with least-privilege accounts, backed by a tested restore procedure, and documented well enough that a stranger can run it.

Interview preparation targets what Pune panels actually ask a database candidate: write a query on a whiteboard, explain why an index is not being used, describe an isolation level and the anomaly it prevents, normalise a badly designed table, and talk through a slow query you personally fixed. Resume, LinkedIn and GitHub are rewritten around the capstone, and two mock interviews are run and reviewed.