Editing MySQL (section)

===Deployment===
MySQL can be built and installed manually from source code, but it is more commonly installed from a binary package unless special customizations are required. On most [[Linux distribution]]s, the [[package management system]] can download and install MySQL with minimal effort, though further configuration is often required to adjust security and optimization settings.

[[File:LAMP software bundle.svg|thumb|400px|[[LAMP (software bundle)|LAMP]] software bundle, displayed here together with [[Squid (software)|Squid]].]]

Though MySQL began as a low-end alternative to more powerful proprietary databases, it has gradually evolved to support higher-scale needs as well. It is still most commonly used in small to medium scale single-server deployments, either as a component in a [[LAMP (software bundle)|LAMP]]-based web application or as a standalone database server. Much of MySQL's appeal originates in its relative simplicity and ease of use, which is enabled by an ecosystem of open source tools such as [[phpMyAdmin]].
In the medium range, MySQL can be scaled by deploying it on more powerful hardware, such as a multi-processor server with gigabytes of memory.

There are, however, limits to how far performance can scale on a single server ('scaling up'), so on larger scales, multi-server MySQL ('scaling out') deployments are required to provide improved performance and reliability. A typical high-end configuration can include a powerful master database which handles data write operations and is [[Database replication|replicated]] to multiple slaves that handle all read operations.<ref>{{cite web |title = The future of replication in MySQL |publisher = Facebook |url= https://www.facebook.com/note.php?note_id=126049465932 |access-date =2009-12-09 }}</ref> The master server continually pushes binlog events to connected slaves so in the event of failure a slave can be promoted to become the new master, minimizing downtime. Further improvements in performance can be achieved by caching the results from database queries in memory using [[memcached]], or breaking down a database into smaller chunks called [[Shard (database architecture)|shards]] which can be spread across a number of distributed server clusters.<ref>{{cite web |title=Database Sharding |publisher=Code Futures |url = http://www.codefutures.com/dbshards-cloud/|access-date = 2009-12-09 |url-status=dead |archive-url = https://web.archive.org/web/20100116031912/http://codefutures.com/dbshards-cloud/|archive-date=16 January 2010}}</ref>