Πλήρης Οδηγός Βελτιστοποίησης Βάσης Δεδομένων WordPress και άλλων CMS
Αν το WordPress site σου είναι αργό, το πρόβλημα δεν είναι πάντα το frontend.
Συχνά, η βάση δεδομένων κρύβει ανεκμετάλλευτο performance.
Σε αυτόν τον οδηγό θα δεις πώς με εργαλεία όπως aapanel + phpMyAdmin μπορείς να βελτιώσεις:
- ⚡ Ταχύτητα
- 🔒 Σταθερότητα
- 📈 PageSpeed Score
🧰 Τι είναι το aaPanel (και γιατί το χρησιμοποιούμε)
💡 Free & Paid Version
- 🟢 Free version
Περιλαμβάνει όλα τα βασικά:- διαχείριση MySQL
- phpMyAdmin
- δημιουργία databases
- εργαλεία όπως Repair & Optimize
- 🔵 Paid version (Pro)
Προσφέρει επιπλέον:- advanced security
- monitoring
- automation εργαλεία.
🧠 Γιατί το χρησιμοποιούμε σε αυτόν τον οδηγό
Το aaPanel μας επιτρέπει:
- να κάνουμε εύκολα Repair & Optimize
- να δούμε engines (InnoDB / MyISAM)
- να διαχειριστούμε tables χωρίς command line
📥 Import μόνο της βάσης
👉 Δεν χρειάζεται ολόκληρο site
Μπορείς απλά:
- Να δημιουργήσεις ένα database στο aaPanel
- Να κάνεις import το .sql file
- Να δουλέψεις πάνω στη βάση (optimization, collation, κλπ)
🏁 Συμπέρασμα
“Το aaPanel είναι ένα lightweight αλλά powerful εργαλείο που σου επιτρέπει να κάνεις database optimization χωρίς να μπλέξεις με πολύπλοκο server setup και σου επιτρέπει να χρησιμοποιήσεις την τελευταία έκδοση της MariaDB 11.4 για αναβάθμιση σε ταχύτητα από παλαιότερη έκδοση MySQL αν αποφασίσεις να το χρησιμοποιήσεις σαν το νέο σου Panel.”
Απο aaPanel -> Databases -> tools βλέπουμε το character encoding της βάσης μας , στην περίπτωση μας πριν την βελτιστοποίηση ήταν ως εξής:
Ανάλυση Charset / Collation
🧾 Λίστα & Πλήθος
| Collation | Πλήθος Πινάκων |
|---|---|
utf8mb4_unicode_520_ci |
24 |
utf8mb3_general_ci |
18 |
utf8mb4_unicode_ci |
6 |
latin1_swedish_ci |
1 |
binary |
1 |
🔍 Τι βλέπουμε εδώ
Η βάση είναι fragmented σε multiple charsets/collations, κάτι που:
- ❌ μειώνει performance (joins / queries)
- ❌ δημιουργεί risk για encoding bugs (ειδικά σε ελληνικά)
- ❌ δυσκολεύει optimization & indexing
🧨 Το πραγματικό πρόβλημα (Tech Insight)
1. ⚠️ Mixed UTF8 Versions
utf8mb3→ deprecatedutf8mb4→ modern standard (WordPress default πλέον)
2. ⚠️ Inconsistent Collations
utf8mb4_unicode_ciutf8mb4_unicode_520_ci
👉 subtle differences σε sorting/comparisons → potential bugs
3. 🚨 Outliers (Red Flags)
❌ latin1_swedish_ci
- Κλασικό legacy MySQL default
👉 αυτό μόνο του μπορεί να σπάσει queries με joins
binary
- Αυτό θα το αφήσουμε ως έχει
🛠️ Optimization Strategy (με aapanel + phpMyadmin)
🎯 Goal:
👉 100% utf8mb4 + ίδιο collation παντού
🛑 Backup πρώτα
Πριν κάνεις οτιδήποτε:
- full DB dump
“+10 PageSpeed με ένα click; Ναι — αλλά όχι για τον λόγο που νομίζεις”
Χρησιμοποιώντας το https://pagespeed.web.dev/
και βλέποντας μόνο το mobile score τρέχουμε πρώτα πριν κάνουμε οτιδήποτε να δούμε το αρχικό score μας με fragmented multiple charsets/collations
και μετά τρέχοντας από aaPanel -> Databases -> tools , επιλέγουμε όλους του πίνακες και κάνουμε Repair και μετά Optimize.
📊 Πριν vs Μετά (Quick Breakdown)
| Metric | Πριν | Μετά | Insight |
|---|---|---|---|
| Performance Score | 62–68 | 73 | ✅ +10 boost |
| FCP | 3.3s | 3.3s | ➖ ίδιο |
| LCP | 5.6s → 5.3s | ~5.3–5.4s | ⚡ μικρή βελτίωση |
| TBT | 400ms → 270ms | 10–40ms | 🔥 huge improvement |
| CLS | 0.007 | 0.005 | ✔ already good |
| Speed Index | 3.8s → 3.6s | 3.6s | μικρό gain |
🔥 Το πιο σημαντικό insight
👉 Το boost δεν ήρθε από rendering speed — αλλά από CPU blocking
Δηλαδή:
- ❌ Δεν φόρτωσε πιο γρήγορα το περιεχόμενο (FCP ίδιο)
- ❌ Δεν άλλαξε δραματικά το LCP
- ✅ Μειώθηκε δραστικά το blocking (TBT)
🧠 Τι έκανε το “Repair & Optimize” πραγματικά;
1. 🧹 Table defragmentation
- καθάρισε fragmented indexes
- λιγότερο disk I/O
2. ⚡ Faster queries
- WordPress queries (options, postmeta) έγιναν πιο γρήγορα
- λιγότερο waiting → λιγότερο blocking JS execution
3. 🧠 Better backend response time (TTFB indirectly)
👉 Αυτό μεταφράζεται σε:
- πιο γρήγορο initial HTML
- λιγότερο JS queuing
💥 Γιατί έπεσε τόσο πολύ το TBT;
Αυτό είναι το πιο “blog-worthy” σημείο:
“Database latency doesn’t just slow your backend — it cascades into frontend blocking.”
Πρακτικά:
- πιο αργό DB → πιο αργό PHP → delayed scripts
- delayed scripts → browser waits → ↑ TBT
👉 Με optimization:
- scripts εκτελούνται πιο “καθαρά”
- λιγότερα main-thread blocks
Τώρα θα πάμε να φτιάξουμε την κωδικοποίηση στους πίνακες και τα δεδομένα μας.
aaPanel -> Databases -> phpMyAdmin επιλέγουμε την βάση μας και πατάμε το κουμπί Operations στο τελευταίο πεδίο Collation επιλέγουμε utf8mb4_unicode_520_ci
Γιατί utf8mb4 και όχι utf8mb3?
🧠 utf8mb3 vs utf8mb4 — The Difference That Actually Matters
| Feature | utf8mb3 | utf8mb4 |
|---|---|---|
| Bytes per char | έως 3 bytes | έως 4 bytes |
| Emoji support | ❌ No | ✅ Yes |
| Full Unicode | ❌ Όχι | ✅ Ναι |
| WordPress support | ⚠️ Deprecated | ✅ Standard |
| MySQL status | ❌ Deprecated | ✅ Recommended |
🧬 1. Core Difference (το πιο σημαντικό)
👉 utf8mb3
- Υποστηρίζει μόνο χαρακτήρες μέχρι 3 bytes
- Δηλαδή:
- βασικά λατινικά ✔
- ελληνικά ✔
- emoji ❌
👉 utf8mb4
- Υποστηρίζει μέχρι 4 bytes
- Δηλαδή:
- όλα τα παραπάνω ✔
- emoji ✔
- σύγχρονα unicode symbols ✔
😱 Real Example
Αν αποθηκεύσεις:
Σε utf8mb3:
👉 είτε:
- error
- είτε κόβεται το emoji
- είτε corrupt data
Σε utf8mb4:
👉 αποθηκεύεται κανονικά ✅
⚠️ 2. Γιατί υπάρχει ακόμα το utf8mb3;
Ιστορικά:
- Το MySQL ονόμασε λάθος το
utf8 - Το
utf8= utf8mb3 στην πραγματικότητα
👉 huge legacy issue
🚨 3. Deprecation Status
- MySQL 8+:
utf8mb3→ deprecated- στο μέλλον θα αφαιρεθεί
👉 άρα:
Αν το site μεγαλώσει → θα έχεις θέματα αν μείνεις σε mb3
Γιατί utf8mb4_unicode_520_ci και όχι utf8mb4_general_ci ?
Αυτό είναι το σημείο που οι περισσότεροι κάνουν “τυφλές” επιλογές — αλλά εδώ κρύβεται η λεπτομέρεια.
🔍
| Collation | Accuracy | Speed | Recommendation |
|---|---|---|---|
utf8mb4_general_ci |
❌ χαμηλή | ⚡ πιο γρήγορο | ❌ όχι για σοβαρό site |
utf8mb4_unicode_ci |
✅ καλή | ⚡ ελαφρώς πιο αργό | 👍 safe επιλογή |
utf8mb4_unicode_520_ci |
✅🔥 καλύτερη | ⚡ ίδιο περίπου | ⭐ BEST |
🧬 Τι είναι το Collation (με απλά λόγια)
Δεν είναι encoding — είναι:
“πώς συγκρίνονται και ταξινομούνται τα strings”
Παράδειγμα:
ß = ss ?
👉 εδώ μπαίνει το collation
⚙️ 1. utf8mb4_general_ci
🧠 Χαρακτηριστικά:
- παλιό, simplified
- δεν ακολουθεί πλήρως Unicode rules
❌ Προβλήματα:
- λάθος sorting σε πολλές γλώσσες
- λιγότερο accurate comparisons
✔ Πότε χρησιμοποιείται:
- legacy apps
- όταν θες “γρήγορο και απλό”
⚙️ 2. utf8mb4_unicode_ci
🧠 Χαρακτηριστικά:
- βασισμένο σε Unicode standard
- πιο σωστό linguistic sorting
✔ Πλεονεκτήματα:
- σωστά comparisons (π.χ. ελληνικά, γερμανικά)
- πιο predictable behavior
⚠️:
- λίγο πιο “βαρύ” (αλλά πρακτικά δεν θα το δεις)
⚙️ 3. utf8mb4_unicode_520_ci
🧠 Χαρακτηριστικά:
- βασισμένο σε Unicode 5.2
- πιο updated rules
🔥 Πλεονεκτήματα:
- καλύτερο sorting από
unicode_ci - πιο accurate σε edge cases
🧠 Real Example (για να καταλάβεις τη διαφορά)
Σε κάποια collations:
- searches
- ORDER BY
- indexing
🔥 WordPress Reality
Το WordPress:
- default →
utf8mb4_unicode_ci - plugins → κάνουν ό,τι θέλουν 😅
- σύγχρονα setups → πάνε σε
utf8mb4_unicode_520_ci
🚀 Final Blog Take
“Charset makes your data compatible.
Collation makes your data behave correctly.”
Και αν έκανες όλα αυτά που αναφέρονται σε αυτό το άρθρο:
✔ έφερες consistency
✔ απέφυγες future bugs
✔ έκανες το DB σου “production-ready”
μετά τρέχοντας από aaPanel -> Databases -> tools , επιλέγουμε όλους του πίνακες και κάνουμε Repair και μετά Optimize ξανά.
🔥 Το Highlight
TBT: 20ms (από 140–240ms πριν)
👉 Αυτό είναι HUGE improvement.
🧠 Τι σημαίνει πρακτικά
- Ο browser πλέον:
- εκτελεί JS χωρίς καθυστερήσεις
- δεν “κολλάει” στο main thread
- Το site φαίνεται πιο responsive
🤔 Γιατί όμως έγινε αυτό;
1️⃣ Database έγινε “clean state”
Το repair/optimize:
- καθάρισε fragmentation
- έκανε rebuild indexes
- βελτίωσε query execution
👉 λιγότερο delay → scripts φορτώνουν πιο ομαλά
2️⃣ Better timing (PageSpeed factor)
Αυτό είναι σημαντικό:
Lighthouse είναι extremely sensitive στο timing
👉 Αν:
- server response ήταν λίγο πιο γρήγορο
- scripts ήρθαν πιο synced
→ TBT μπορεί να πέσει δραματικά
🔍 Τι μαθαίνουμε από όλα αυτά
✔ Database affects:
- TBT (πολύ)
- responsiveness
❌ Database does NOT affect:
- LCP (images, layout)
- FCP (rendering pipeline)
“Αν έχεις παλιό CMS και αλλάξεις το Engine απο MyISAM → InnoDB κερδίζεις ακόμα μεγαλύτερη ταχύτητα”
Από aaPanel -> Databases -> tools βλέπουμε το Engine σε όλους του πίνακες και μπορούμε να την μετατρέψουμε σε InnoDB
🔍 Γιατί η InnoDB είναι η καλύτερη μηχανή αποθήκευσης;
👉 InnoDB > MyISAM σε όλα σχεδόν τα cases
👉 Αλλά: “Δεν είναι απλά convert — θέλει σωστή δομή (indexes, primary keys)”
⚙️ MyISAM vs InnoDB (Real-World Comparison)
| Feature | MyISAM | InnoDB |
|---|---|---|
| Transactions | ❌ No | ✅ Yes |
| Locking | Table-level | Row-level |
| Speed (writes) | ⚡ fast | ⚡ optimized |
| Concurrency | ❌ Poor | ✅ Excellent |
| Crash recovery | ❌ Risky | ✅ Safe |
| Foreign keys | ❌ No | ✅ Yes |
🧠 Core Insight
“MyISAM is fast when you’re alone. InnoDB is fast when real users exist.”
🔥 Γιατί InnoDB είναι καλύτερο για WordPress
1️⃣ Row-level locking
- MyISAM → lock όλο το table 😬
- InnoDB → lock μόνο τη γραμμή
👉 huge difference σε:
- πολλούς χρήστες
- AJAX requests
- WooCommerce sites
2️⃣ Crash safety
- MyISAM → μπορεί να corrupt tables
- InnoDB → recovery mechanism
👉 λιγότερα:
- “table crashed” errors
- repair ανάγκες
3️⃣ Better performance σε real traffic
- ειδικά σε:
wp_postswp_postmetawp_options
⚠️ Πού θέλει προσοχή (πολύ σημαντικό)
🧨 1. Primary Keys
InnoDB:
- απαιτεί PRIMARY KEY
Αν δεν υπάρχει:
👉 δημιουργεί hidden key → bad performance
🧨 2. Indexes
Μετά το conversion:
- κάποια queries μπορεί να γίνουν πιο αργά
- χρειάζεται:
- σωστά indexes
- ειδικά σε meta tables
🏁 Real-World Take
✔ Αν έχεις παλιό site με MyISAM:
- convert σε InnoDB → real improvement
🚀 Συγχαρητήρια
Αν έκανες όλα αυτα που σου πρότεινε το blog.easytechnology.gr το επίσημο Blog του EasyTechnology.gr :
- DB = clean ✔
- Charset = σωστό ✔
- Engine = InnoDB ✔
