Install MySQL on Windows, Linux, Containers, and Verify the Toolchain

Learning outcomes

Installation is not complete when an installer says “Finished.” A working MySQL lab requires a server process, a reachable endpoint, known credentials, a compatible client, and a successful query. This lesson uses that operational definition on Windows, Linux, and containers.

Pick one lab route, then make it observable

You do not need three MySQL installations. Choose one primary path and learn the same verification sequence. A native Windows or Linux service is useful for understanding traditional administration. A container is excellent for repeatable, disposable labs and later failure injection. The SQL behavior is server behavior; the packaging changes how you start, stop, configure, persist, and inspect it.

Windows: install the server, then verify the service

Oracle’s MySQL 8.4 Windows documentation recommends the MSI path with MySQL Configurator for the simplest native setup. The server does not become useful merely because files were copied; configuration must create a data directory, configure accounts and networking, and start the service.

# Discover likely MySQL servicesGet-Service *MySQL*# Verify executables on PATH (or use their full install path)mysqld --versionmysql --versionmysqlsh --version   # optional; may not be installed# Connect over TCP; -p prompts instead of putting the password in historymysql -h 127.0.0.1 -P 3306 -u root -p

If mysql is “not recognized,” that is a client PATH problem, not proof that the server is absent. If the Windows service is stopped, the client can be installed perfectly and still fail to connect. Separate executable discovery, service state, endpoint reachability, and authentication during diagnosis.

Linux: prefer the current Oracle repository guidance

Oracle documents APT, Yum, SLES, direct package, generic binary, and container methods. Native distribution repositories may lag the current supported MySQL family, so check exactly which package/version you are about to install instead of assuming apt install mysql-server or an equivalent command gives the course baseline.

# Service name can vary by package/distribution; inspect rather than guess.systemctl status mysql || systemctl status mysqldmysqld --versionmysql --version# Prompt for the password interactivelymysql -h 127.0.0.1 -P 3306 -u root -p

On a systemd-based host, service status and logs are evidence about process startup. They are not a substitute for an authenticated SQL connection. After the service is healthy, perform the server-side checks shown later in this lesson.

Containers: make persistence and ports explicit

A container is the fastest way to create a disposable server, but two details matter immediately: the server listens on its container port while the host may map a different port, and the database must use a persistent volume if you expect data to survive container replacement.

# Use a disposable lab password, not a real production secret.# Verify the current official MySQL 8.4 image/tag before running this command.docker volume create mysql84_servicehub_datadocker run --name mysql84-servicehub \  -e MYSQL_ROOT_PASSWORD=<DISPOSABLE_LAB_PASSWORD> \  -p 3307:3306 \  -v mysql84_servicehub_data:/var/lib/mysql \  -d mysql:8.4docker ps --filter name=mysql84-servicehubdocker logs mysql84-servicehubdocker exec -it mysql84-servicehub mysql -u root -p

The host-side port in this example is 3307 to avoid colliding with a native MySQL service on 3306. A connection from the host would therefore target 127.0.0.1:3307. Inside the container, the server still normally listens on its configured internal port.

The universal verification query

Once any installation route gives you an authenticated session, run the same checks. This is the point where “package installed” becomes “database server verified.”

SELECT 'mysql server reachable' AS checkpoint;SELECT VERSION() AS server_version,       @@version_comment AS version_comment,       @@hostname AS server_hostname,       @@port AS server_port,       CONNECTION_ID() AS connection_id,       USER() AS client_identity,       CURRENT_USER() AS authenticated_account,       DATABASE() AS current_schema;SELECT @@default_storage_engine AS default_storage_engine,       @@character_set_server AS server_character_set,       @@collation_server AS server_collation;SHOW SESSION STATUS LIKE 'Ssl_cipher';

DATABASE() may be NULL because no default schema has been selected yet. That is normal. The server port can differ from 3306. TLS status can differ for local socket/TCP configurations. The important lesson is to observe rather than assume.

A wrong approach: diagnose every connection error as “bad password”

The client error message often points to a layer. “Connection refused” or timeout usually suggests process/listener/network problems before authentication. “Access denied” means the client reached a server that rejected authentication or account-host matching. “Unknown database” means authentication can succeed while schema selection fails. A PATH error occurs before any network attempt.

Diagnosing one layer at a time is faster and safer than repeatedly reinstalling the server.

Hands-on lab: produce a verified installation report

Create a file named environment.md and record the following non-secret observations. The report should allow you to reproduce the same lab or explain why another machine behaves differently.

Installation route: Windows MSI / Oracle Linux packages / containerServer version: from SELECT VERSION()Server edition/comment: from @@version_commentServer endpoint: local TCP host + port, or documented local socketmysql client version: from mysql --versionMySQL Shell version: from mysqlsh --version, or not installedDefault storage engine: from @@default_storage_engineServer character set/collation: record observed valuesTLS cipher for this session: record observed value/emptyContainer image + volume name: if applicableDate verified: YYYY-MM-DD

Production judgment: installation is the first runbook

Production installation adds supported-platform checks, secure bootstrap, service identity, filesystem permissions, network exposure, TLS certificates, configuration management, monitoring, backup integration, patch policy, and rollback planning. Do not copy a development container command directly into production and call it an architecture.

For this course, one disposable local Community Server is enough. The next lesson turns it into a safe long-lived learning environment with a dedicated schema, least-privilege application account, seed/reset scripts, and positive/negative authorization tests.

References

• MySQL 8.4 — Installing MySQL
• Installing MySQL on Microsoft Windows
• Installing MySQL on Linux
• Deploying MySQL with Docker containers
• mysql command-line client