<![CDATA[AdminsForum - aaPanel Databases & phpMyAdmin Guides]]>

<![CDATA[AdminsForum - aaPanel Databases & phpMyAdmin Guides]]> https://adminsforum.com/ Thu, 15 Oct 2026 07:04:52 +0000 MyBB <![CDATA[Fix Unknown Collation Error 1273 in aaPanel Imports]]> https://adminsforum.com/Thread-guide-fix-unknown-collation-error-1273-in-aapanel-imports Thu, 15 Oct 2026 14:56:37 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-unknown-collation-error-1273-in-aapanel-imports “Unknown collation” error 1273 during an import means the target server does not recognize a collation name used by the SQL. Confirm the target version and available collations before editing the dump or changing server defaults.

A collation defines comparison and sorting behavior. Choosing a recognized name can make a table definition run, but does not prove that sorting, equality and unique keys still match the source application's requirements.

.jpg

database-collation-20261015.jpg (Size: 126.79 KB / Downloads: 3)
Original AdminsForum private lab results, formatted as a transcript rather than a screenshot.

1. Save the original dump and exact error
Keep an unchanged copy of the source export. Record the source database product/version, target product/version, failing statement or import position and exact collation name. Do not publish a full dump: it can contain account data, secrets and private content.

An import can execute earlier statements before stopping. Do not repeatedly run an edited file into a partly populated live database. Rehearse recovery in an isolated destination and verify what already committed before planning any production action.

2. Ask the target server what it supports
From an authorized database session on the actual destination, run:

Code:

SELECT VERSION();
SHOW COLLATION WHERE Collation = 'utf8mb4_0900_ai_ci';
SHOW COLLATION WHERE Charset = 'utf8mb4';

Replace the specific name with the one in your error. An empty result for that name is evidence of absence on that server. The broader listing helps identify supported choices; it does not establish their semantic equivalence.

Do not infer support from “MySQL-compatible” branding alone. MariaDB versions differ, and newer versions can support names missing from older versions. A web-panel version is not the database-server version.

3. Locate where the unsupported name is declared
Review the failing schema statement in a protected local copy of the export. The name may appear at database, table or column level, or in another SQL expression. Identify each relevant declaration and its associated character set.

Changing only the destination database default will not necessarily override explicit table or column declarations inside the dump. Conversely, replacing every matching word in a dump can alter places you did not intend, including data text. Prefer a controlled schema/export compatibility plan over a blind global replacement.

If using aaPanel's installed database tools or phpMyAdmin, confirm you selected the isolated destination before any import. The import workflow itself is covered in the related guide; this tutorial investigates collation compatibility rather than repeating the upload steps.

4. What our private lab actually tested
The target was MariaDB 10.11.10 in the aaPanel lab. We used one disposable InnoDB table in a separate test database.

The target's collation lookup returned no row for utf8mb4_0900_ai_ci. Creating the test table with that explicit collation returned 1273: Unknown collation.
The lookup confirmed utf8mb4_unicode_ci was available. A disposable table using that candidate and utf8mb4 was created successfully.
In the candidate table's unique text key, inserting Cafe and then café produced a duplicate-key error 1062 on the second value. That demonstrates equality behavior relevant to a unique key.
A separate string containing a four-byte character was stored, and its hexadecimal bytes were read back to verify that small example.

We did not run those comparisons on the source collation, which was unavailable on this server. The test therefore does not prove either equality or difference between the candidate and a real source database. It does not validate every language, sort order, trailing-space rule or application query.

The disposable table was removed and the connection closed. No global database defaults or production tables changed. The normal HTTPS website returned 200 afterward.

5. Choose a migration approach based on requirements
Check whether the source application's export process supports the intended target server. A compatible target version or a supported export/schema strategy may be preferable to substituting collation names.

If considering a different target collation, list the behavior the application needs: language-specific ordering, case and accent treatment, comparisons, joins and unique-key rules. Test representative real-world values in a protected staging environment with appropriate data handling.

Do not assume utf8mb4_unicode_ci is the right answer merely because it worked in this small lab. It was a candidate used to demonstrate the decision process, not a universal recommendation. An upgrade also needs its own application compatibility, backup and rollback plan; do not upgrade a shared database service just to clear one import message.

6. Keep character encoding and collation separate
A compatible collation name must be considered alongside the character set and connection encoding. Removing four-byte character support to make a declaration parse can lose valid application data.

Verify representative non-ASCII and four-byte characters through the application's actual connection and read-back path. The lab's one stored string was only a narrow check, not proof that an entire export was correctly encoded or converted.

Also inspect column-level definitions after the staged import. A successful connection or a changed database default alone does not prove every text column uses the intended configuration.

7. Rehearse the import and validate the data
Use a fresh isolated target with the reviewed schema plan and keep the original dump unchanged. Confirm the schema creates, then load representative data and inspect errors and warnings. Investigate any new duplicate-key conflict; do not drop unique constraints to force completion.

Compare expected table and row counts, selected values, relationships and application behavior. Exercise searches, sorting, equality checks and uniqueness-sensitive actions. Include values that distinguish the application's required comparison rules. Check that no rows were silently skipped.

An import tool reporting completion is only one signal. The database must also preserve the application's intended data semantics. Our lab was not a full migration rehearsal and did not test a production cutover.

8. Plan the production change and rollback separately
Back up the destination and confirm a tested restore path before any real import or schema conversion. Record the reviewed changes and their scope. Schedule the migration around writes and application consistency needs, then verify the same checks after cutover.

Do not overwrite or empty a live database as a troubleshooting shortcut. If the rehearsal shows incompatible behavior, stop the conversion plan and resolve that mismatch before touching the live target.

For a support request
Include both server products/versions, exact unsupported name, redacted failing schema and whether the destination is empty or partially imported. Describe the required comparison behavior without attaching private data dumps.

Related guides
Import a SQL database file in aaPanel
Investigate duplicate-key error 1062
Back up and restore a database

Technical references
MariaDB supported character sets and collations
Setting character sets and collations
MySQL-to-MariaDB compatibility considerations]]> “Unknown collation” error 1273 during an import means the target server does not recognize a collation name used by the SQL. Confirm the target version and available collations before editing the dump or changing server defaults.

A collation defines comparison and sorting behavior. Choosing a recognized name can make a table definition run, but does not prove that sorting, equality and unique keys still match the source application's requirements.

.jpg

Code:

SELECT VERSION();
SHOW COLLATION WHERE Collation = 'utf8mb4_0900_ai_ci';
SHOW COLLATION WHERE Charset = 'utf8mb4';

The target's collation lookup returned no row for utf8mb4_0900_ai_ci. Creating the test table with that explicit collation returned 1273: Unknown collation.
The lookup confirmed utf8mb4_unicode_ci was available. A disposable table using that candidate and utf8mb4 was created successfully.
In the candidate table's unique text key, inserting Cafe and then café produced a duplicate-key error 1062 on the second value. That demonstrates equality behavior relevant to a unique key.
A separate string containing a four-byte character was stored, and its hexadecimal bytes were read back to verify that small example.

We did not run those comparisons on the source collation, which was unavailable on this server. The test therefore does not prove either equality or difference between the candidate and a real source database. It does not validate every language, sort order, trailing-space rule or application query.

The disposable table was removed and the connection closed. No global database defaults or production tables changed. The normal HTTPS website returned 200 afterward.

5. Choose a migration approach based on requirements
Check whether the source application's export process supports the intended target server. A compatible target version or a supported export/schema strategy may be preferable to substituting collation names.

If considering a different target collation, list the behavior the application needs: language-specific ordering, case and accent treatment, comparisons, joins and unique-key rules. Test representative real-world values in a protected staging environment with appropriate data handling.

Do not assume utf8mb4_unicode_ci is the right answer merely because it worked in this small lab. It was a candidate used to demonstrate the decision process, not a universal recommendation. An upgrade also needs its own application compatibility, backup and rollback plan; do not upgrade a shared database service just to clear one import message.

6. Keep character encoding and collation separate
A compatible collation name must be considered alongside the character set and connection encoding. Removing four-byte character support to make a declaration parse can lose valid application data.

Verify representative non-ASCII and four-byte characters through the application's actual connection and read-back path. The lab's one stored string was only a narrow check, not proof that an entire export was correctly encoded or converted.

Also inspect column-level definitions after the staged import. A successful connection or a changed database default alone does not prove every text column uses the intended configuration.

7. Rehearse the import and validate the data
Use a fresh isolated target with the reviewed schema plan and keep the original dump unchanged. Confirm the schema creates, then load representative data and inspect errors and warnings. Investigate any new duplicate-key conflict; do not drop unique constraints to force completion.

Compare expected table and row counts, selected values, relationships and application behavior. Exercise searches, sorting, equality checks and uniqueness-sensitive actions. Include values that distinguish the application's required comparison rules. Check that no rows were silently skipped.

An import tool reporting completion is only one signal. The database must also preserve the application's intended data semantics. Our lab was not a full migration rehearsal and did not test a production cutover.

8. Plan the production change and rollback separately
Back up the destination and confirm a tested restore path before any real import or schema conversion. Record the reviewed changes and their scope. Schedule the migration around writes and application consistency needs, then verify the same checks after cutover.

Do not overwrite or empty a live database as a troubleshooting shortcut. If the rehearsal shows incompatible behavior, stop the conversion plan and resolve that mismatch before touching the live target.

For a support request
Include both server products/versions, exact unsupported name, redacted failing schema and whether the destination is empty or partially imported. Describe the required comparison behavior without attaching private data dumps.

Related guides
Import a SQL database file in aaPanel
Investigate duplicate-key error 1062
Back up and restore a database

Technical references
MariaDB supported character sets and collations
Setting character sets and collations
MySQL-to-MariaDB compatibility considerations]]> <![CDATA[Fix MariaDB Foreign Key Errors 1451 and 1452 in aaPanel]]> https://adminsforum.com/Thread-guide-fix-mariadb-foreign-key-errors-1451-and-1452-in-aapanel Thu, 15 Oct 2026 14:33:22 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-mariadb-foreign-key-errors-1451-and-1452-in-aapanel MariaDB foreign-key errors protect relationships between records. Error 1452 usually concerns a child that cannot reference the required parent; error 1451 can block a parent change when dependent rows still exist. Read the actual constraint before changing data.

This guide demonstrates both errors in disposable InnoDB tables in a separate aaPanel lab database. We kept checks enabled and verified a valid parent-before-child insertion. No live application relationship or cascade policy was changed.

.jpg

database-foreignkey-20261015.jpg (Size: 125.72 KB / Downloads: 3)
Original AdminsForum lab evidence, formatted as a transcript rather than a screenshot.

1. Capture the exact error and operation
Record the database error code, time, application action or import step, table and named constraint. If the website shows only a generic failure, inspect its private application log and correlate the site logs through aaPanel's Website → PHP Project → Log workflow. Labels may vary.

The two error meanings are:

Code:

1452: Cannot add or update a child row:
a foreign key constraint fails

1451: Cannot delete or update a parent row:
a foreign key constraint fails

A child stores the reference; a parent supplies the referenced key. For example, a lab task can refer to a lab project. This relationship is a database rule, not a missing PHP extension or a web-server timeout.

Redact identifiers and private values before sharing messages. Do not publish a complete customer database dump to illustrate an error.

2. Identify the actual relationship
In an authorized database session, inspect the affected table's definition:

Code:

SHOW CREATE TABLE your_child_table;

Use the correct database and real table name. Find the named FOREIGN KEY, child columns, referenced table and columns, and ON DELETE/ON UPDATE actions. Composite relationships need every relevant column checked.

Review the intended parent and dependent rows with scoped read-only queries. Use parameterized application queries for untrusted input. Do not assume that two IDs with the same number represent the same entity after a migration or import.

A constraint-creation failure is a different investigation from these tested data-write errors. If the table or foreign key cannot be created, collect that error and the full relevant definitions instead of applying a data-insert fix.

3. Diagnose a 1452 child-write failure
Check whether the referenced parent exists in the intended database and whether the application supplied the right reference. An import can load child data before its parents, omit a required parent set or map old IDs incorrectly.

For genuinely new related records, create the legitimate parent through the supported application workflow before its child. Do not invent a dummy customer or project merely to satisfy a database check. A wrong child reference may need an input correction, not a new parent.

Also review the application's transaction boundaries and error handling. A parent created in a different uncommitted or failed operation may not be available as the caller expects. This guide's lab used simple committed statements, not a concurrent import or cross-service workflow.

4. Diagnose a 1451 parent-change failure
Identify which child records still reference the parent and what the existing relationship policy requires. Under a restrictive policy, blocking the parent deletion can be the correct result.

Decide through the application's data-lifecycle rules whether the parent should be retained, archived or handled by an authorized workflow for related records. Do not delete child rows just to make a parent-delete command succeed. Those rows may be business history.

Cascade and set-null policies are schema-design decisions with their own conditions and consequences. Do not add ON DELETE CASCADE as a generic repair. Our test deliberately used RESTRICT and did not validate an application's deletion policy.

5. What the private aaPanel lab demonstrated
On MariaDB 10.11.10, we created one disposable parent table and one child table using InnoDB. The child required a parent ID and the named foreign key used restrictive update and delete actions.

Parent 1 and child 1 → parent 1 were inserted successfully.
A new child pointing to nonexistent parent 999 returned 1452.
Deleting parent 1 while its child existed returned 1451. A check confirmed the original parent remained.
We then added an intentionally valid new parent 2, followed by child 2 → parent 2. Both succeeded.
The final child relationships were 1 → 1 and 2 → 2. The orphan check returned zero, with the constraint retained and foreign-key checks still enabled.

These are synthetic relationships, not a repair of customer data. The two disposable tables were removed in dependency order after testing and the connection closed. No global database setting changed, and the normal HTTPS website returned 200 afterward.

6. Do not bypass integrity to hide the error
Disabling checks or dropping the relationship can let a write proceed without establishing a valid data model. That does not prove the application is repaired. Keep the constraint while investigating the input, import sequence and intended record lifecycle.

Similarly, blindly ignoring an error can leave an expected child absent. Check actual row counts and relationships rather than only whether a tool reports completion. If a specialized restore procedure requires different handling, rehearse and validate that separate procedure in an isolated destination first.

7. Verify relationships with a scoped orphan check
For a simple non-null single-column relationship, an illustrative read-only check is:

Code:

SELECT COUNT(*) AS orphan_count
FROM your_child_table AS ch
LEFT JOIN your_parent_table AS pa ON pa.id = ch.parent_id
WHERE pa.id IS NULL;

Replace the names and join with the actual relationship. This example assumes the child reference must be non-null; optional null relationships and composite keys need an adapted query. Do not treat a generic join as a complete database integrity audit.

Run bounded checks on the intended data scope, with an administrator reviewing cost on large tables. Do not paste all matching customer rows publicly.

8. Apply a justified correction and test the application
Back up affected data before corrective writes. Use supported application workflows and verify that the intended identities and permissions match. For an import, confirm the source-to-target key mapping and parent/child order in a staging rehearsal.

Afterward inspect the intended parent and child records, verify no expected rows were silently skipped and confirm the constraint remains. Test the original safe application action and check for new matching errors. One successful insert does not validate every relationship in a restore.

Keep a rollback plan and remove disposable test fixtures. Do not drop live tables or wipe related records as a troubleshooting shortcut.

For a support request
Share the version, error code, named relationship, redacted definitions, operation type and recent import/deployment changes. Explain the intended parent/child outcome without sharing credentials or private records.

Related guides
Investigate duplicate-key error 1062
Import a database file in aaPanel
Back up and restore a database

Technical references
MariaDB foreign-key constraints
Foreign-key relationship rules
MariaDB error 1451
MariaDB error 1452]]> MariaDB foreign-key errors protect relationships between records. Error 1452 usually concerns a child that cannot reference the required parent; error 1451 can block a parent change when dependent rows still exist. Read the actual constraint before changing data.

This guide demonstrates both errors in disposable InnoDB tables in a separate aaPanel lab database. We kept checks enabled and verified a valid parent-before-child insertion. No live application relationship or cascade policy was changed.

.jpg

Code:

1452: Cannot add or update a child row:
a foreign key constraint fails

1451: Cannot delete or update a parent row:
a foreign key constraint fails

Code:

SHOW CREATE TABLE your_child_table;

Parent 1 and child 1 → parent 1 were inserted successfully.
A new child pointing to nonexistent parent 999 returned 1452.
Deleting parent 1 while its child existed returned 1451. A check confirmed the original parent remained.
We then added an intentionally valid new parent 2, followed by child 2 → parent 2. Both succeeded.
The final child relationships were 1 → 1 and 2 → 2. The orphan check returned zero, with the constraint retained and foreign-key checks still enabled.

Code:

SELECT COUNT(*) AS orphan_count
FROM your_child_table AS ch
LEFT JOIN your_parent_table AS pa ON pa.id = ch.parent_id
WHERE pa.id IS NULL;

Replace the names and join with the actual relationship. This example assumes the child reference must be non-null; optional null relationships and composite keys need an adapted query. Do not treat a generic join as a complete database integrity audit.

Run bounded checks on the intended data scope, with an administrator reviewing cost on large tables. Do not paste all matching customer rows publicly.

8. Apply a justified correction and test the application
Back up affected data before corrective writes. Use supported application workflows and verify that the intended identities and permissions match. For an import, confirm the source-to-target key mapping and parent/child order in a staging rehearsal.

Afterward inspect the intended parent and child records, verify no expected rows were silently skipped and confirm the constraint remains. Test the original safe application action and check for new matching errors. One successful insert does not validate every relationship in a restore.

Keep a rollback plan and remove disposable test fixtures. Do not drop live tables or wipe related records as a troubleshooting shortcut.

For a support request
Share the version, error code, named relationship, redacted definitions, operation type and recent import/deployment changes. Explain the intended parent/child outcome without sharing credentials or private records.

Related guides
Investigate duplicate-key error 1062
Import a database file in aaPanel
Back up and restore a database

Technical references
MariaDB foreign-key constraints
Foreign-key relationship rules
MariaDB error 1451
MariaDB error 1452]]> <![CDATA[Fix MariaDB Duplicate Entry Error 1062 in aaPanel]]> https://adminsforum.com/Thread-guide-fix-mariadb-duplicate-entry-error-1062-in-aapanel Thu, 15 Oct 2026 14:12:05 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-mariadb-duplicate-entry-error-1062-in-aapanel MariaDB error 1062 means an operation would violate a primary or unique key. Identify the key and intended record before changing the SQL: ignoring the error can leave the new data unsaved, while replacing a record can change existing data.

This guide uses a disposable InnoDB table in a separate aaPanel lab database. It demonstrates duplicate rejection, INSERT IGNORE warnings and a corrected distinct record while retaining the unique constraint. No live application data was edited.

.jpg

database-duplicate-20261015.jpg (Size: 123.29 KB / Downloads: 3)
Original AdminsForum lab results, formatted as a transcript rather than a screenshot.

1. Capture the exact error and operation
Record the time, application action or import step, table and key name from the error. A browser may show only a generic failure, so inspect the application's private logs and correlate the website error log in aaPanel.

Under Website → PHP Project, find the site and open its Log control. Panel labels vary. Redact user values, email addresses and customer identifiers before sharing an error; the duplicate value can appear directly in the message.

Our harmless lab example was:

Code:

1062 / SQLSTATE 23000
Duplicate entry 'AF-LAB-001' for key 'uq_reference'

The named key was a unique reference index in our test, not necessarily the primary key. Do not assume every 1062 involves an auto-increment ID.

2. Identify the columns protected by the named key
In an authorized database session, inspect the affected table's structure or run a scoped read-only check:

Code:

SHOW INDEX FROM your_table;

Replace your_table with the actual intended table in the correct database. Find the reported key name and its column sequence. A unique key can cover more than one column; the required uniqueness may be a combination rather than one field by itself.

Then inspect only the relevant existing record using an appropriately parameterized query in the application or a careful read-only lookup in the administration tool. Do not paste untrusted values directly into SQL. Keep sensitive row contents private.

A key conflict tells you the database rejected that value combination. It does not tell you whether the new input is wrong, the operation was repeated or an existing record should be updated.

3. Decide what the operation was supposed to do

Create a genuinely new record: verify the source supplied the right unique identifier. Correct invalid input through the supported application workflow.
Repeat the same logical request: inspect idempotency handling and the existing outcome. Repeating a request should not accidentally create a second order or account.
Update an existing record: verify identity, authorization and intended changes before using the application's supported update path.
Import or restore data: determine whether the target already contains earlier imported rows and what the source's merge policy is. Test the complete restore plan in an isolated destination.

Do not invent a new business identifier just to suppress an error. The lab's second identifier was deliberately a separate synthetic record; that does not make renaming a real customer's reference a valid repair.

4. What our private test demonstrated
We used MariaDB 10.11.10 and a disposable two-column data example with an auto-increment primary key and an additional unique reference index. Initially AF-LAB-001 had value 10.

A normal INSERT of AF-LAB-001 with value 20 returned 1062. A read-back confirmed the existing value remained 10.
The same duplicate with INSERT IGNORE reported zero affected rows and warning 1062. A read-back again showed only the existing value 10: the proposed value 20 was not saved.
An intentionally distinct AF-LAB-002 record with value 20 inserted successfully. The final reference/value pairs were AF-LAB-001 → 10 and AF-LAB-002 → 20.

The unique index remained in place throughout. These were single-row, autocommit statements against a private fixture, not a test of a real import, concurrent application requests or multi-statement rollback handling. The disposable table was removed and its connection closed afterward. No global settings changed, and the normal HTTPS website returned 200.

5. Understand why common shortcuts change behavior

INSERT IGNORE: our test showed that a duplicate can become a warning while the row is not inserted. Review affected rows, warnings and final data; a command completing without an error is not proof all input was saved.
ON DUPLICATE KEY UPDATE: this intentionally updates on a key conflict. That can be appropriate only when its identity and update semantics match the application. It is not a harmless switch for any failed import.
REPLACE: this has replacement behavior involving deletion and insertion of conflicting rows. Do not treat it as a generic in-place update; review relationships, triggers and application consequences first.
Dropping uniqueness: removing an intended unique index can permit invalid duplicates. Keep the integrity rule unless an independently reviewed schema-design change actually requires something different.

Only the ordinary INSERT and INSERT IGNORE paths were tested here. The other options are design considerations, not verified repairs for your application.

6. Check repeated imports and concurrent requests
For an import, record where it stopped and whether earlier statements committed. Re-running a partially applied file can encounter records already present. Do not empty a live database or delete the conflicting row without a validated restore or merge plan and backup.

For an application, two requests can race even when each first checks whether a value exists. Retain the database constraint and handle the conflict according to the application's intended operation. An existence check alone is not a concurrency guarantee.

If the conflict is specifically on PRIMARY, inspect how that identifier was supplied and the deployment/import history. Do not reset auto-increment values or renumber related records merely because the error mentions a duplicate.

7. Apply one justified correction and read the data back
Back up affected data and configuration before any real corrective write. Use the application's supported identity and authorization checks. If a restore is intended, rehearse it in an isolated database and verify counts, relationships and representative records.

After the correction, check the actual row values and expected outcome as well as the SQL result. Inspect warnings in the same relevant session where appropriate. Confirm the unique key is retained and unrelated data is unchanged.

Our lab used a distinct synthetic record because it represented a new item. A real repeated request may instead need to return the existing result, and a real update may need a specifically authorized change. Choose the behavior from the business operation, not the easiest way to silence 1062.

For a support request
Include the database version, key name, operation type, timestamp, whether the target already held data and a redacted error. Do not share passwords, complete SQL dumps or customer records.

Related guides
Import a SQL database file in aaPanel
Back up and restore a database
Review query plans and indexes

Technical references
MariaDB error 1062
INSERT IGNORE behavior
ON DUPLICATE KEY UPDATE behavior
REPLACE semantics]]> MariaDB error 1062 means an operation would violate a primary or unique key. Identify the key and intended record before changing the SQL: ignoring the error can leave the new data unsaved, while replacing a record can change existing data.

This guide uses a disposable InnoDB table in a separate aaPanel lab database. It demonstrates duplicate rejection, INSERT IGNORE warnings and a corrected distinct record while retaining the unique constraint. No live application data was edited.

.jpg

Code:

1062 / SQLSTATE 23000
Duplicate entry 'AF-LAB-001' for key 'uq_reference'

Code:

SHOW INDEX FROM your_table;

Create a genuinely new record: verify the source supplied the right unique identifier. Correct invalid input through the supported application workflow.
Repeat the same logical request: inspect idempotency handling and the existing outcome. Repeating a request should not accidentally create a second order or account.
Update an existing record: verify identity, authorization and intended changes before using the application's supported update path.
Import or restore data: determine whether the target already contains earlier imported rows and what the source's merge policy is. Test the complete restore plan in an isolated destination.

A normal INSERT of AF-LAB-001 with value 20 returned 1062. A read-back confirmed the existing value remained 10.
The same duplicate with INSERT IGNORE reported zero affected rows and warning 1062. A read-back again showed only the existing value 10: the proposed value 20 was not saved.
An intentionally distinct AF-LAB-002 record with value 20 inserted successfully. The final reference/value pairs were AF-LAB-001 → 10 and AF-LAB-002 → 20.

INSERT IGNORE: our test showed that a duplicate can become a warning while the row is not inserted. Review affected rows, warnings and final data; a command completing without an error is not proof all input was saved.
ON DUPLICATE KEY UPDATE: this intentionally updates on a key conflict. That can be appropriate only when its identity and update semantics match the application. It is not a harmless switch for any failed import.
REPLACE: this has replacement behavior involving deletion and insertion of conflicting rows. Do not treat it as a generic in-place update; review relationships, triggers and application consequences first.
Dropping uniqueness: removing an intended unique index can permit invalid duplicates. Keep the integrity rule unless an independently reviewed schema-design change actually requires something different.

Only the ordinary INSERT and INSERT IGNORE paths were tested here. The other options are design considerations, not verified repairs for your application.

6. Check repeated imports and concurrent requests
For an import, record where it stopped and whether earlier statements committed. Re-running a partially applied file can encounter records already present. Do not empty a live database or delete the conflicting row without a validated restore or merge plan and backup.

For an application, two requests can race even when each first checks whether a value exists. Retain the database constraint and handle the conflict according to the application's intended operation. An existence check alone is not a concurrency guarantee.

If the conflict is specifically on PRIMARY, inspect how that identifier was supplied and the deployment/import history. Do not reset auto-increment values or renumber related records merely because the error mentions a duplicate.

7. Apply one justified correction and read the data back
Back up affected data and configuration before any real corrective write. Use the application's supported identity and authorization checks. If a restore is intended, rehearse it in an isolated database and verify counts, relationships and representative records.

After the correction, check the actual row values and expected outcome as well as the SQL result. Inspect warnings in the same relevant session where appropriate. Confirm the unique key is retained and unrelated data is unchanged.

Our lab used a distinct synthetic record because it represented a new item. A real repeated request may instead need to return the existing result, and a real update may need a specifically authorized change. Choose the behavior from the business operation, not the easiest way to silence 1062.

For a support request
Include the database version, key name, operation type, timestamp, whether the target already held data and a redacted error. Do not share passwords, complete SQL dumps or customer records.

Related guides
Import a SQL database file in aaPanel
Back up and restore a database
Review query plans and indexes

Technical references
MariaDB error 1062
INSERT IGNORE behavior
ON DUPLICATE KEY UPDATE behavior
REPLACE semantics]]> <![CDATA[Fix MariaDB Lock Wait Timeout Error 1205 in aaPanel]]> https://adminsforum.com/Thread-guide-fix-mariadb-lock-wait-timeout-error-1205-in-aapanel Thu, 15 Oct 2026 14:07:57 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-mariadb-lock-wait-timeout-error-1205-in-aapanel MariaDB error 1205 means a lock wait exceeded its applicable allowance. Identify what is blocked, who holds the needed lock and what happened to the transaction before retrying.

A lock-wait timeout is not the same as error 1213, a detected deadlock. This guide demonstrates an InnoDB row-lock timeout in a separate lab database, including an earlier update that remained pending until explicit rollback. Do not deliberately block live application tables to reproduce it.

.jpg

database-lockwait-20261015.jpg (Size: 126.1 KB / Downloads: 4)
Original AdminsForum private lab evidence, formatted as a transcript rather than a screenshot.

1. Confirm the error and incident time
Record the application action, time and timezone, job or request identifier and exact database error. A website may expose only a generic 500, so inspect the application's private log and correlate it with the website logs in aaPanel.

Under Website → PHP Project, locate the affected site and open its Log control. Panel labels can vary. Do not publish raw SQL, user values, credentials or full log dumps.

The error being investigated is:

Code:

1205 / HY000
Lock wait timeout exceeded; try restarting transaction

A long request is not sufficient evidence of this error. Also establish which kind of lock is involved: this lab tested an InnoDB record lock, not every metadata or table-lock situation that can produce a timeout.

2. Understand blocking without a deadlock
One transaction can hold a row lock while another waits for it. The holder does not have to be waiting for the second transaction; there may be no circular dependency. If the applicable wait expires first, the waiting statement fails.

An application that begins a transaction and leaves it open while doing other work can retain locks longer than intended. A currently idle-looking connection may still own an open transaction. Identify the transaction lifecycle rather than assuming only a visibly running SQL statement can block another request.

3. Inspect the relevant live transaction while it is waiting
An authorized database administrator can inspect the InnoDB transaction information. For a known application connection ID, an illustrative scoped query is:

Code:

SELECT trx_id, trx_state, trx_started, trx_wait_started,
       trx_mysql_thread_id
FROM information_schema.INNODB_TRX
WHERE trx_mysql_thread_id = 12345;

Replace 12345 with the actual connection identified for the incident. Do not guess IDs or assume the phpMyAdmin connection is the same connection serving a website request. Visibility depends on privileges and version; ask the database administrator for the appropriate redacted evidence rather than granting a website account broad access.

In our test the known waiting connection appeared as LOCK WAIT. This is a point-in-time view: after the statement times out or the holder finishes, the same evidence may no longer be present. An administrator may need to correlate transaction and lock-wait information to identify the blocker. Do not publish server-wide diagnostic output containing unrelated queries.

4. Check the effective timeout and rollback behavior
For an authorized session, these read-only checks show relevant settings:

Code:

SELECT @@SESSION.innodb_lock_wait_timeout;
SELECT @@GLOBAL.innodb_rollback_on_timeout;

The first query describes the session running it. It does not prove a different pooled application connection uses the same timeout.

For the InnoDB timeout behavior documented by MariaDB, a timeout normally rolls back the failing statement rather than all earlier work in the transaction. With innodb_rollback_on_timeout enabled, the entire transaction can be rolled back. Confirm the actual setting and your application's transaction state before retrying.

Do not assume the instruction “try restarting transaction” means earlier work disappeared automatically. This is a material difference from a detected deadlock's transaction rollback.

5. What our isolated lab test proved
We used MariaDB 10.11.10 and one disposable two-row InnoDB table inside the existing separate performance-test database. A holding connection updated row 1 without committing. A waiting transaction first updated row 2, then attempted row 1.

Only the waiting test connection received a session-local two-second lock-wait limit. The blocked update returned 1205 after 2.004 seconds.
The server's existing rollback-on-timeout value was 0. Before our explicit rollback, the waiter could still see its earlier uncommitted row-2 increment as 1.
We explicitly rolled back the waiter and the holder. An independent check then saw both row values at 0.
With the blocker released, a fresh complete transaction updated both rows and committed. Both final values were 1.

This was one coordinated timeout, not a production performance benchmark or an automatic-retry implementation. The disposable table was removed and all test connections closed. No global settings changed; we also checked the relevant global timeout and rollback values remained the same. The normal HTTPS website returned 200 afterward.

6. Correct the cause of excessive lock duration
Review where the blocking transaction begins and ends. Check for missing commit or rollback handling, unnecessarily large batches, external network calls inside a transaction and competing operations on the same records.

Use representative staging data to investigate query plans and the records affected. An inefficient scan can increase contention, but adding an index without examining the real workload is not a guaranteed repair. Keep transaction boundaries aligned with the application's consistency requirements.

Do not kill arbitrary database sessions or restart MariaDB as a first response. Ending a holder can trigger rollback and affect other requests. A production intervention needs identification of the owner and the consequences, not just a large elapsed-time number.

7. Recover the whole logical operation deliberately
Use the application's supported transaction handling to return to a known state. If retry is appropriate, apply a bounded retry policy to the complete logical transaction after resolving or allowing for the blocker. Include short backoff and a clear failure path rather than an infinite retry loop.

Do not commit earlier partial work accidentally after catching only the failed statement. Also account for external effects: database rollback cannot unsend an email or undo an external payment. Idempotency and application semantics need their own tests.

Our lab explicitly rolled back before the clean retry. It did not validate any real application's error-handling code or business operation.

8. Change wait budgets only for a measured reason
A longer timeout allows more waiting; it does not release the blocking lock. It can also hold application workers and connections for longer. Consider a change only after understanding the workload, transaction duration and user-facing request budget.

Record the previous value and scope. Session settings and global defaults affect different connections; existing pooled connections may behave differently from newly created ones. Do not apply the lab's two-second value to a live site as a recommendation. Changing global rollback behavior also changes semantics and is outside this tested fix.

9. Verify data and cleanup
Test the original operation and a controlled competing path in staging. Check final values, explicit rollback behavior, bounded retries and application logs. An HTTP 200 response or the absence of one timeout does not prove the transaction completed correctly.

Monitor representative traffic after a justified change and keep a rollback plan. Remove disposable test tables and close diagnostic transactions. Do not leave a manual transaction open in a SQL tool after testing.

For a support request
Include the database version, error code, time, relevant transaction boundaries, scoped redacted wait evidence and recent changes. Do not share full customer SQL or database passwords.

Related guides
Distinguish MariaDB deadlock error 1213
Inspect query plans and index changes
Correlate website errors with logs

Technical references
MariaDB error 1205
InnoDB lock-wait and rollback settings
InnoDB transaction diagnostics
MariaDB ROLLBACK behavior]]> MariaDB error 1205 means a lock wait exceeded its applicable allowance. Identify what is blocked, who holds the needed lock and what happened to the transaction before retrying.

A lock-wait timeout is not the same as error 1213, a detected deadlock. This guide demonstrates an InnoDB row-lock timeout in a separate lab database, including an earlier update that remained pending until explicit rollback. Do not deliberately block live application tables to reproduce it.

.jpg

Code:

1205 / HY000
Lock wait timeout exceeded; try restarting transaction

Code:

SELECT trx_id, trx_state, trx_started, trx_wait_started,
       trx_mysql_thread_id
FROM information_schema.INNODB_TRX
WHERE trx_mysql_thread_id = 12345;

Code:

SELECT @@SESSION.innodb_lock_wait_timeout;
SELECT @@GLOBAL.innodb_rollback_on_timeout;

Only the waiting test connection received a session-local two-second lock-wait limit. The blocked update returned 1205 after 2.004 seconds.
The server's existing rollback-on-timeout value was 0. Before our explicit rollback, the waiter could still see its earlier uncommitted row-2 increment as 1.
We explicitly rolled back the waiter and the holder. An independent check then saw both row values at 0.
With the blocker released, a fresh complete transaction updated both rows and committed. Both final values were 1.

This was one coordinated timeout, not a production performance benchmark or an automatic-retry implementation. The disposable table was removed and all test connections closed. No global settings changed; we also checked the relevant global timeout and rollback values remained the same. The normal HTTPS website returned 200 afterward.

6. Correct the cause of excessive lock duration
Review where the blocking transaction begins and ends. Check for missing commit or rollback handling, unnecessarily large batches, external network calls inside a transaction and competing operations on the same records.

Use representative staging data to investigate query plans and the records affected. An inefficient scan can increase contention, but adding an index without examining the real workload is not a guaranteed repair. Keep transaction boundaries aligned with the application's consistency requirements.

Do not kill arbitrary database sessions or restart MariaDB as a first response. Ending a holder can trigger rollback and affect other requests. A production intervention needs identification of the owner and the consequences, not just a large elapsed-time number.

7. Recover the whole logical operation deliberately
Use the application's supported transaction handling to return to a known state. If retry is appropriate, apply a bounded retry policy to the complete logical transaction after resolving or allowing for the blocker. Include short backoff and a clear failure path rather than an infinite retry loop.

Do not commit earlier partial work accidentally after catching only the failed statement. Also account for external effects: database rollback cannot unsend an email or undo an external payment. Idempotency and application semantics need their own tests.

Our lab explicitly rolled back before the clean retry. It did not validate any real application's error-handling code or business operation.

8. Change wait budgets only for a measured reason
A longer timeout allows more waiting; it does not release the blocking lock. It can also hold application workers and connections for longer. Consider a change only after understanding the workload, transaction duration and user-facing request budget.

Record the previous value and scope. Session settings and global defaults affect different connections; existing pooled connections may behave differently from newly created ones. Do not apply the lab's two-second value to a live site as a recommendation. Changing global rollback behavior also changes semantics and is outside this tested fix.

9. Verify data and cleanup
Test the original operation and a controlled competing path in staging. Check final values, explicit rollback behavior, bounded retries and application logs. An HTTP 200 response or the absence of one timeout does not prove the transaction completed correctly.

Monitor representative traffic after a justified change and keep a rollback plan. Remove disposable test tables and close diagnostic transactions. Do not leave a manual transaction open in a SQL tool after testing.

For a support request
Include the database version, error code, time, relevant transaction boundaries, scoped redacted wait evidence and recent changes. Do not share full customer SQL or database passwords.

Related guides
Distinguish MariaDB deadlock error 1213
Inspect query plans and index changes
Correlate website errors with logs

Technical references
MariaDB error 1205
InnoDB lock-wait and rollback settings
InnoDB transaction diagnostics
MariaDB ROLLBACK behavior]]> <![CDATA[Fix MariaDB Deadlock Error 1213 in aaPanel]]> https://adminsforum.com/Thread-guide-fix-mariadb-deadlock-error-1213-in-aapanel Thu, 15 Oct 2026 13:58:53 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-mariadb-deadlock-error-1213-in-aapanel MariaDB error 1213 means a deadlock was detected and a transaction was chosen for rollback. Investigate the competing transactions and application retry behavior; increasing a timeout does not remove a circular lock dependency.

This guide uses a two-row InnoDB experiment in a separate lab database. It shows one way opposite update orders can deadlock, then verifies a consistent-order comparison. Do not reproduce deliberate lock conflicts against your live application tables.

.jpg

database-deadlock-20261015.jpg (Size: 125.88 KB / Downloads: 3)
Original AdminsForum private lab results, formatted as a transcript rather than a screenshot.

1. Confirm the actual database error
Record the application action, time and timezone, request or job identifier and exact database error code. An application may show only a generic 500, so inspect its private logs as well as the website error log.

In aaPanel open the affected site's Log control under Website → PHP Project and correlate the incident time. If the application has its own log, use that too. Avoid publishing SQL containing customer data, authentication details or private values.

MariaDB identifies this error as:

Code:

1213 / SQLSTATE 40001 / ER_LOCK_DEADLOCK
Deadlock found when trying to get lock; try restarting transaction

Do not confuse it with error 1205, a lock-wait timeout. A slow query or high CPU reading does not by itself prove a deadlock occurred.

2. Understand the circular wait
A simplified two-row case looks like this:

Code:

Transaction A holds row 1 and requests row 2.
Transaction B holds row 2 and requests row 1.

Each transaction is waiting for a lock held by the other. InnoDB can break this cycle by rolling back a victim. The selected victim can vary; do not hard-code application logic around a particular worker always losing.

Consistent ordering can remove this particular cycle, but real transactions can involve multiple tables, indexes, ranges and triggers. Fix the demonstrated conflict rather than assuming every deadlock is a two-row problem.

3. Inspect the most recent InnoDB deadlock report
Through an authorized database administration session, run the read-only diagnostic:

Code:

SHOW ENGINE INNODB STATUS;

Inspect the LATEST DETECTED DEADLOCK section. It can identify the participating transactions, SQL statements, held or requested locks and the rollback victim. Check its timestamp and affected table against your incident.

This output is server-wide and can contain sensitive SQL. Keep the full report private and share a narrowly redacted excerpt. The latest report may belong to another application or a later event; it is not a complete history of every deadlock. If access is denied, ask the database administrator for the relevant excerpt rather than granting broad privileges to a website account.

For repeated incidents, an administrator can assess dedicated deadlock logging and its retention separately. Our experiment did not enable global logging or collect unrelated database queries.

4. What our isolated aaPanel lab tested
The lab ran MariaDB 10.11.10. We created one disposable InnoDB table with two primary-key rows inside the existing separate performance-test database. Only the owned test rows were updated. No production application table or global database setting was changed.

Two transactions first updated different rows, then attempted the other row in opposite order. In this run, A received error 1213 and rolled back; B committed. The latest deadlock section referenced the lab table.
We reset the two test values, then ran both transactions in the same order: row 1 followed by row 2. Both committed in this comparison.
The final values were 2 for row 1 and 2 for row 2, confirming that both successful transactions applied their increments.

This was a coordinated, bounded demonstration with session-local lock-wait limits. It was not a production concurrency benchmark or proof that consistent ordering prevents every possible deadlock. The disposable table was removed and connections closed afterward. No global setting changed, and the normal HTTPS website returned 200.

5. Review the complete application transaction
Find where the transaction begins, what rows and tables it touches, and when it commits or rolls back. Include ORM operations, background jobs and triggers that can acquire additional locks.

Compare the order used by competing code paths. Where the application's correctness permits it, make related operations acquire locks in a consistent order across those paths. Keep transactions focused and avoid unnecessary waiting or external network calls while holding locks.

Also review query plans and indexes when transactions scan or lock more records than expected. Adding an index is not an automatic deadlock cure: confirm the actual access pattern and test correctness and write overhead in staging.

6. Handle retry at the transaction boundary
An application should recognize a deadlock and handle the rolled-back transaction deliberately. If retry is appropriate for the operation, retry the complete logical transaction using the framework or driver's supported transaction mechanism, with a bounded number of attempts and a short backoff.

Do not blindly rerun only the last SQL statement or retry indefinitely. Emails, payments and other external side effects need separate idempotency and consistency handling; a database rollback does not undo an external action. Confirm the application's transaction state before issuing another attempt.

Our lab recorded the deadlock and rollback explicitly; it did not implement or validate a real application's automatic retry strategy. Test that separately using controlled data.

7. Avoid unrelated server changes
Do not restart MariaDB, disable deadlock detection or increase connection and timeout limits just because one request reported 1213. Those changes do not repair a demonstrated circular lock order and can affect other sites.

Changing isolation levels also changes application semantics. Treat it as an application-design decision requiring appropriate testing, not a generic panel tuning step. Preserve transaction integrity and existing safeguards while gathering evidence.

8. Verify with representative controlled operations
After a code or query change, test the original operation and competing path in staging with bounded concurrency. Check final data, rollback behavior and retry limits, not merely the absence of a browser error. Monitor the relevant deadlock evidence over a representative period.

A single successful pair is useful evidence for a small reproduction, not proof that all workload conflicts are gone. Keep the original code/configuration and a tested rollback plan. Remove disposable test tables and do not delete or unlock real business data to make a test appear successful.

For a useful support request
Provide the database version, error code, time, redacted deadlock excerpt, transaction boundaries and recent application changes. Describe expected data consistency. Do not include database passwords, full customer SQL or server-wide diagnostic dumps.

Related guides
Measure MariaDB query plans and index changes
Correlate website errors with logs
Investigate PHP HTTP 500 errors

Technical references
MariaDB error 1213
SHOW ENGINE INNODB STATUS documentation
InnoDB lock-wait and deadlock settings]]> MariaDB error 1213 means a deadlock was detected and a transaction was chosen for rollback. Investigate the competing transactions and application retry behavior; increasing a timeout does not remove a circular lock dependency.

This guide uses a two-row InnoDB experiment in a separate lab database. It shows one way opposite update orders can deadlock, then verifies a consistent-order comparison. Do not reproduce deliberate lock conflicts against your live application tables.

.jpg

Code:

1213 / SQLSTATE 40001 / ER_LOCK_DEADLOCK
Deadlock found when trying to get lock; try restarting transaction

Code:

Transaction A holds row 1 and requests row 2.
Transaction B holds row 2 and requests row 1.

Code:

SHOW ENGINE INNODB STATUS;

Two transactions first updated different rows, then attempted the other row in opposite order. In this run, A received error 1213 and rolled back; B committed. The latest deadlock section referenced the lab table.
We reset the two test values, then ran both transactions in the same order: row 1 followed by row 2. Both committed in this comparison.
The final values were 2 for row 1 and 2 for row 2, confirming that both successful transactions applied their increments.

This was a coordinated, bounded demonstration with session-local lock-wait limits. It was not a production concurrency benchmark or proof that consistent ordering prevents every possible deadlock. The disposable table was removed and connections closed afterward. No global setting changed, and the normal HTTPS website returned 200.

5. Review the complete application transaction
Find where the transaction begins, what rows and tables it touches, and when it commits or rolls back. Include ORM operations, background jobs and triggers that can acquire additional locks.

Compare the order used by competing code paths. Where the application's correctness permits it, make related operations acquire locks in a consistent order across those paths. Keep transactions focused and avoid unnecessary waiting or external network calls while holding locks.

Also review query plans and indexes when transactions scan or lock more records than expected. Adding an index is not an automatic deadlock cure: confirm the actual access pattern and test correctness and write overhead in staging.

6. Handle retry at the transaction boundary
An application should recognize a deadlock and handle the rolled-back transaction deliberately. If retry is appropriate for the operation, retry the complete logical transaction using the framework or driver's supported transaction mechanism, with a bounded number of attempts and a short backoff.

Do not blindly rerun only the last SQL statement or retry indefinitely. Emails, payments and other external side effects need separate idempotency and consistency handling; a database rollback does not undo an external action. Confirm the application's transaction state before issuing another attempt.

Our lab recorded the deadlock and rollback explicitly; it did not implement or validate a real application's automatic retry strategy. Test that separately using controlled data.

7. Avoid unrelated server changes
Do not restart MariaDB, disable deadlock detection or increase connection and timeout limits just because one request reported 1213. Those changes do not repair a demonstrated circular lock order and can affect other sites.

Changing isolation levels also changes application semantics. Treat it as an application-design decision requiring appropriate testing, not a generic panel tuning step. Preserve transaction integrity and existing safeguards while gathering evidence.

8. Verify with representative controlled operations
After a code or query change, test the original operation and competing path in staging with bounded concurrency. Check final data, rollback behavior and retry limits, not merely the absence of a browser error. Monitor the relevant deadlock evidence over a representative period.

A single successful pair is useful evidence for a small reproduction, not proof that all workload conflicts are gone. Keep the original code/configuration and a tested rollback plan. Remove disposable test tables and do not delete or unlock real business data to make a test appear successful.

For a useful support request
Provide the database version, error code, time, redacted deadlock excerpt, transaction boundaries and recent application changes. Describe expected data consistency. Do not include database passwords, full customer SQL or server-wide diagnostic dumps.

Related guides
Measure MariaDB query plans and index changes
Correlate website errors with logs
Investigate PHP HTTP 500 errors

Technical references
MariaDB error 1213
SHOW ENGINE INNODB STATUS documentation
InnoDB lock-wait and deadlock settings]]> <![CDATA[Tune MariaDB Queries in aaPanel with EXPLAIN and Index Tests]]> https://adminsforum.com/Thread-guide-tune-mariadb-queries-in-aapanel-with-explain-and-index-tests Wed, 14 Oct 2026 20:17:01 +0800 DEV]]> https://adminsforum.com/Thread-guide-tune-mariadb-queries-in-aapanel-with-explain-and-index-tests A slow website does not automatically need a larger database buffer or more connections. First identify the query, inspect its execution plan and measure a targeted change. This guide demonstrates that workflow in a separate MariaDB lab database.

Tested environment: aaPanel Free 8.0.7, Ubuntu 22.04.5 and MariaDB 10.11.10. MySQL and MariaDB releases differ; verify your installed version before copying configuration advice. We used 50,000 synthetic rows and changed no global database settings.

1. Identify the database and establish a baseline
Open aaPanel → Databases and confirm which service and database the website uses. Inspect application logs and slow queries rather than assuming the homepage represents all workloads. Administrative diagnostics require suitable database permissions; keep credentials out of commands, screenshots and public tutorials.

Code:

SELECT VERSION();
SHOW VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','slow_query_log','long_query_time');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Max_used_connections','Innodb_buffer_pool_reads','Innodb_buffer_pool_read_requests');

Our lab had a 384MiB InnoDB buffer pool, max_connections 200, slow logging enabled and a 3-second threshold. Maximum used connections was 3 at that observation. These are observations, not recommended settings for every server.
Counters may accumulate since startup. Take interval snapshots under representative traffic; a one-time cache ratio is not enough to justify allocating more RAM.

2. Find the actual slow query
If slow logging is enabled, review its configured path through an administrator session. Logs can contain query text and user data: keep access restricted and do not upload raw logs to a public thread. A 3-second threshold will miss many shorter queries; choose a diagnostic threshold deliberately and monitor storage overhead.
Find frequently repeated queries as well as individually expensive ones. Record execution count, latency and examined rows. A fast query executed thousands of times may still consume significant resources.

3. Create a separate practice database
Use a disposable database, never a production table, for this example. Our new database was af_performance_index_lab_20261014. In MariaDB 10.11, the sequence table below provides synthetic integers; this syntax is not a portable MySQL recipe.

Code:

CREATE DATABASE af_performance_index_lab_20261014;
USE af_performance_index_lab_20261014;
CREATE TABLE events (
  id INT PRIMARY KEY,
  account_id INT NOT NULL,
  status VARCHAR(16) NOT NULL,
  payload VARCHAR(100) NOT NULL
) ENGINE=InnoDB;
INSERT INTO events
SELECT seq, MOD(seq,1000),
       IF(MOD(seq,2)=0,'active','closed'), REPEAT('x',100)
FROM seq_1_to_50000;

Check that your chosen database name does not already exist. This example creates only synthetic data; adapt names and versions for your own isolated lab.

4. Inspect the query plan before changing anything

Code:

EXPLAIN SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';

SQL_NO_CACHE is used here to exclude MariaDB's query-result cache; it does not empty the InnoDB buffer pool. Do not copy this clause into an incompatible database release.
Our plan showed type ALL and an estimated 50,000 rows. EXPLAIN estimates are not measured execution counts, but this plan indicates a full table scan to evaluate the filters.
The query returned 50 matching rows. Record the result so that a faster but incorrect rewrite is not accepted.

5. Test a targeted composite index

Code:

ALTER TABLE events
  ADD INDEX idx_account_status(account_id,status);
ANALYZE TABLE events;
EXPLAIN SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';

The new plan used idx_account_status, type ref and an estimated 50 rows. It also reported Using index: this count query can be satisfied from the index entries needed for the filters.
Index design depends on the actual predicates, sorting and joins. Column order matters for other queries using only part of a composite index. Avoid creating an index for every column: indexes use storage and add work to writes.
On a large production table, building an index can consume time, space and locks. Check version-specific online DDL behavior, back up and plan the change before applying it to real data.

6. Compare the same query
We used MariaDB session profiling for this lab: one warmup followed by ten measured executions in each phase. The same database session setting and query were used before and after. Warm data remained possible in the buffer pool; this is not a cold-storage benchmark.

Code:

SET profiling=1;
SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';
SHOW PROFILES;

Repeat the SELECT for your sample and inspect its reported duration. Session profiling is version-specific; use the diagnostic tools available in your actual database release. Disable temporary profiling when finished.

.jpg

database-index-comparison-20261014.jpg (Size: 115.87 KB / Downloads: 5)
AdminsForum formatted transcript of the original lab test, not a terminal screenshot.

The median of ten measured executions was about 12.72ms before and 0.188ms after. Both phases returned 50 rows. This supports this index for this synthetic query; it does not promise the same improvement for every website or establish production capacity.

7. Tune resources only after reviewing evidence
For InnoDB buffer sizing, account for the working data set and sustained physical reads, while reserving memory for PHP-FPM, Nginx, OS, mail and other services. Dedicated database-server percentage rules are unsuitable for every shared aaPanel VPS.
For max_connections, inspect concurrent connections, application pooling and per-connection memory. Raising the limit can worsen overload. Our observed maximum of 3 did not justify increasing the limit of 200.
Change one setting at a time, retain its original value, validate the database configuration and repeat representative workloads. Monitor swap, OOM events, errors and query latency. A restart can temporarily alter cache warmth and distort comparisons.

8. Verify the website and retain a rollback plan
Test real reads and writes, not just this SELECT. Compare execution plans and results, then monitor normal traffic. For our disposable table, the index can be removed with:

Code:

ALTER TABLE events DROP INDEX idx_account_status;

Code:

SELECT VERSION();
SHOW VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','slow_query_log','long_query_time');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Max_used_connections','Innodb_buffer_pool_reads','Innodb_buffer_pool_read_requests');

Code:

CREATE DATABASE af_performance_index_lab_20261014;
USE af_performance_index_lab_20261014;
CREATE TABLE events (
  id INT PRIMARY KEY,
  account_id INT NOT NULL,
  status VARCHAR(16) NOT NULL,
  payload VARCHAR(100) NOT NULL
) ENGINE=InnoDB;
INSERT INTO events
SELECT seq, MOD(seq,1000),
       IF(MOD(seq,2)=0,'active','closed'), REPEAT('x',100)
FROM seq_1_to_50000;

Code:

EXPLAIN SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';

Code:

ALTER TABLE events
  ADD INDEX idx_account_status(account_id,status);
ANALYZE TABLE events;
EXPLAIN SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';

Code:

SET profiling=1;
SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';
SHOW PROFILES;

Code:

ALTER TABLE events DROP INDEX idx_account_status;

Do not remove an existing production index without checking its other uses. We retained this isolated lab database and its index for repeatable demonstrations; no application database was modified.

Continue with PHP-FPM memory limits to balance the shared server, rather than tuning each service as though it owns all RAM.

References: MariaDB EXPLAIN and SHOW PROFILES.]]> <![CDATA[Check MySQL Status and Error Logs in aaPanel]]> https://adminsforum.com/Thread-guide-check-mysql-status-and-error-logs-in-aapanel Tue, 13 Oct 2026 22:20:23 +0800 DEV]]> https://adminsforum.com/Thread-guide-check-mysql-status-and-error-logs-in-aapanel When a website reports a database error, check the database service, connection settings and logs before restarting MySQL or changing passwords. aaPanel's MySQL manager can show the service controls, live status metrics and database error log in one place.

This guide is for MySQL and MariaDB installations managed by aaPanel. A database problem is different from an Nginx or PHP-FPM problem: a working panel login does not prove that every website component is healthy.

What we verified
We inspected aaPanel 8.0.7 on our Ubuntu 22.04 lab on 13 October 2026. The software button was labelled mariadb_10.11.6, while the database startup log reported MariaDB 10.11.10. We also completed a SQL import and saw its two-row table in the database tools.

The Service screen displayed Current state: Stop, yet Current status returned a launch time, connections and database statistics. This is a verified panel-status mismatch, not proof that MariaDB stopped. We did not restart or reinstall the database to make the label change, and we have not confirmed the underlying cause of that mismatch.

1. Identify which layer is failing
Record the exact error, affected website and time. Keep the message private if it contains a username, client IP or application path.

A database connection error in the application: check its database host, database name, username and password, as well as service availability.
An import error: use the Import dialog's Show Logs output. A failed SQL statement may leave a partially imported database.
502 or 503 from the web server: inspect the web server/PHP path too. Those HTTP errors do not, by themselves, identify a broken database.

Only one website failing while other database-backed websites work points toward a site-specific problem. All sites failing together makes the shared database service or VPS resources more relevant. Use these clues to narrow the checks; they are not a diagnosis on their own.

2. Open the database service manager
Go to Databases → MySQL, then click the installed service button above the database list. In our lab it was labelled Mysql mariadb_10.11.6. The same manager can also be reached through the installed MySQL/MariaDB app in App Store.

Select Service. Read the state and available controls. Start, Restart and Reload are actions; do not click them merely to test whether the screen responds.

.jpg

mysql-state-mismatch-20261013.jpg (Size: 178.89 KB / Downloads: 5)
Actual lab screen: the Service label says Stop. The next checks are essential before treating this label as the server's actual state.

If the server is truly stopped, first collect the startup error and identify the reason. A restart can briefly interrupt every application using the service, and repeatedly restarting does not repair an invalid configuration, full disk or corrupted data.

3. Cross-check Current status
Open Current status in the manager. Wait for the figures to load. Note the launch time, connection totals and active connections. A momentary -- or NaN while the screen loads is not a final diagnostic result.

Our screen returned real database metrics after loading, even though the Service tab's label remained Stop. Combined with the successful SQL import, this established that the database was responding to the panel at that time.

.jpg

mysql-live-status-20261013.jpg (Size: 244.8 KB / Downloads: 5)
The lab's loaded status metrics. Counters and percentages vary with workload; they are not tuning targets to copy to another server.

Do not increase every memory or cache setting because a panel tip suggests it. An apparently low hit rate can be irrelevant to your engine or workload. For a 4 GB VPS, raising several per-connection buffers can make memory pressure worse.

4. Read Error log
Select Error log. Read the most recent relevant lines and compare their timestamps with the failure time. Server and browser time zones can differ.

.jpg

mysql-error-log-view-20261013.jpg (Size: 288.45 KB / Downloads: 4)
Our log contains startup information and a ready for connections message. That message is historical; the import and Current status checks provide the additional evidence that the lab is responding now.

Pay attention to severity and context:

Note: often normal startup or background information. Our log's FEEDBACK plugin disabled note was not evidence of a stopped database.
Warning: something to review, not automatically a fatal error. Our binary-log retention warning did not prevent the sample import.
Error: investigate the named file, setting or resource and the lines immediately around it.

Do not use Empty log while diagnosing a failure. It removes useful evidence; it does not resolve the cause. Save a private copy of the relevant output before changing anything. Redact usernames, IP addresses, paths containing secrets and SQL data before posting screenshots for support.

5. Distinguish a connection problem from a login problem
The exact database-client error helps decide what to check next:

2002 or 2003, cannot connect: verify the service and the configured host, port or Unix socket. A running service may still be listening somewhere different from the client's settings.
1045, access denied for user: review the username, password and allowed host/account permissions. The root, aaPanel login and website database passwords are separate credentials.
1044, access denied to a database: check that the application account is permitted to use the requested database.
1049, unknown database: compare the configured database name with the database list and confirm that creation or migration completed.

These are general error interpretations from MariaDB's documentation. We did not reproduce each error or change credentials during this read-only walkthrough.

For an application on the same VPS, opening MySQL port 3306 to everyone is not a fix for a wrong local password or database name. Likewise, changing the database root password is not a substitute for correcting a website's own connection settings.

6. Optional checks through SSH
If you already have working SSH access, these read-only checks can help corroborate a misleading panel label:

Code:

/etc/init.d/mysqld status
ss -lntp | grep ':3306'
ls -lh /www/server/data/*.err

Use your actual port if it differs from 3306. An open listening port proves that a listener exists; it does not prove that the application can authenticate or query its tables.

A test with the website's own database account is more specific:

Code:

/www/server/mysql/bin/mysql --protocol=TCP   --host=127.0.0.1 --port=3306   --user=YOUR_DATABASE_USER --password   YOUR_DATABASE_NAME -e "SELECT 1;"

The --password option prompts interactively. Do not put a real password directly into a command that may be saved in shell history. This TCP test is different from a localhost Unix-socket connection; use the connection method your application actually requires. The optional SSH commands were not executed in this walkthrough because the lab's browser terminal was not connected.

7. Change one confirmed cause, then verify the website
Back up before a configuration change. Correct the specific failing setting rather than reinstalling the database or deleting files from its data directory. Retest the same connection and a real application page after the change.

If the Service label and successful database queries disagree, report the evidence to aaPanel support: panel version, engine version from the server/log, state screenshot, Current status and the outcome of a harmless query. A hostname/PID-file or process-detection issue is a possibility to investigate, not a cause we have proved on this lab.

Related guides:
Import a SQL Database File in aaPanel
Fix 502 Bad Gateway and 503 Errors in aaPanel

References:
aaPanel MySQL manager
aaPanel service-management commands
MariaDB connection troubleshooting]]> When a website reports a database error, check the database service, connection settings and logs before restarting MySQL or changing passwords. aaPanel's MySQL manager can show the service controls, live status metrics and database error log in one place.

This guide is for MySQL and MariaDB installations managed by aaPanel. A database problem is different from an Nginx or PHP-FPM problem: a working panel login does not prove that every website component is healthy.

What we verified
We inspected aaPanel 8.0.7 on our Ubuntu 22.04 lab on 13 October 2026. The software button was labelled mariadb_10.11.6, while the database startup log reported MariaDB 10.11.10. We also completed a SQL import and saw its two-row table in the database tools.

The Service screen displayed Current state: Stop, yet Current status returned a launch time, connections and database statistics. This is a verified panel-status mismatch, not proof that MariaDB stopped. We did not restart or reinstall the database to make the label change, and we have not confirmed the underlying cause of that mismatch.

1. Identify which layer is failing
Record the exact error, affected website and time. Keep the message private if it contains a username, client IP or application path.

A database connection error in the application: check its database host, database name, username and password, as well as service availability.
An import error: use the Import dialog's Show Logs output. A failed SQL statement may leave a partially imported database.
502 or 503 from the web server: inspect the web server/PHP path too. Those HTTP errors do not, by themselves, identify a broken database.

Note: often normal startup or background information. Our log's FEEDBACK plugin disabled note was not evidence of a stopped database.
Warning: something to review, not automatically a fatal error. Our binary-log retention warning did not prevent the sample import.
Error: investigate the named file, setting or resource and the lines immediately around it.

2002 or 2003, cannot connect: verify the service and the configured host, port or Unix socket. A running service may still be listening somewhere different from the client's settings.
1045, access denied for user: review the username, password and allowed host/account permissions. The root, aaPanel login and website database passwords are separate credentials.
1044, access denied to a database: check that the application account is permitted to use the requested database.
1049, unknown database: compare the configured database name with the database list and confirm that creation or migration completed.

Code:

/etc/init.d/mysqld status
ss -lntp | grep ':3306'
ls -lh /www/server/data/*.err

Code:

/www/server/mysql/bin/mysql --protocol=TCP   --host=127.0.0.1 --port=3306   --user=YOUR_DATABASE_USER --password   YOUR_DATABASE_NAME -e "SELECT 1;"

The --password option prompts interactively. Do not put a real password directly into a command that may be saved in shell history. This TCP test is different from a localhost Unix-socket connection; use the connection method your application actually requires. The optional SSH commands were not executed in this walkthrough because the lab's browser terminal was not connected.

7. Change one confirmed cause, then verify the website
Back up before a configuration change. Correct the specific failing setting rather than reinstalling the database or deleting files from its data directory. Retest the same connection and a real application page after the change.

If the Service label and successful database queries disagree, report the evidence to aaPanel support: panel version, engine version from the server/log, state screenshot, Current status and the outcome of a harmless query. A hostname/PID-file or process-detection issue is a possibility to investigate, not a cause we have proved on this lab.

Related guides:
Import a SQL Database File in aaPanel
Fix 502 Bad Gateway and 503 Errors in aaPanel

References:
aaPanel MySQL manager
aaPanel service-management commands
MariaDB connection troubleshooting]]> <![CDATA[Import a SQL Database File in aaPanel (Step by Step)]]> https://adminsforum.com/Thread-guide-import-a-sql-database-file-in-aapanel-step-by-step Tue, 13 Oct 2026 22:08:05 +0800 DEV]]> https://adminsforum.com/Thread-guide-import-a-sql-database-file-in-aapanel-step-by-step To import a MySQL or MariaDB database in aaPanel, open Databases, choose Import beside the correct database, upload your SQL file and confirm the import. Back up first, then verify the imported tables and data.

This walkthrough uses aaPanel's built-in importer. You do not need to expose phpMyAdmin publicly or open MySQL port 3306 to the internet.

Tested lab
Ubuntu 22.04 and aaPanel 8.0.7, tested on 13 October 2026. The database startup log reports MariaDB 10.11.10; the panel software button still displays the mariadb_10.11.6 label. The destination was our isolated adminsforum_lab tutorial database. We created a fresh backup, imported one sample table and verified that the panel lists it with a Row number of 2. The existing af_backup_check table remained present with one row. We did not import into the WordPress or webmail databases.

Before you begin

A running MySQL or MariaDB service and a database created in aaPanel.
A trusted .sql export containing database structure and/or data, not website files.
Enough free disk space for the upload, extracted archive and database.
A current backup of anything already in the destination database.

For a migration, start with a separate empty destination database. A SQL dump can contain DROP TABLE, DELETE, TRUNCATE or USE statements. aaPanel warns that an import may overwrite the selected database. Do not test an unfamiliar file against a working website database.

1. Choose the destination and create a backup
Open Databases → MySQL. The MySQL tab also manages our installed MariaDB service. Read the database name carefully; it is not always the same as the website domain.

If the database does not exist, follow Create a Database and User in aaPanel first. Use a separate database rather than importing over another site's tables.

In the destination row, click its Backup value, such as Exists(1), to open the backup details. Click Backup, wait for the background task to finish and confirm that a new dated archive appears with a non-zero size. Keep a private copy off the VPS for important data. Do not post a real SQL dump or its passwords in a support thread.

.jpg

sql-import-backup-20261013.jpg (Size: 52.91 KB / Downloads: 8)
Our pre-import backup appeared in the list before we continued. Backup creation alone is not a tested restore.

2. Check the file before uploading
Use the SQL export from the source database or a harmless sample for practice. A renamed spreadsheet, HTML error page or ZIP without a SQL file is not a database export.

For this rehearsal, our file was plain SQL. It created a uniquely named training table and inserted two rows:

Code:

CREATE TABLE IF NOT EXISTS af_import_lesson_20261013 (
  id INT NOT NULL PRIMARY KEY,
  title VARCHAR(120) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO af_import_lesson_20261013 (id, title) VALUES
  (1, 'Welcome to AdminsForum'),
  (2, 'SQL import verified')
ON DUPLICATE KEY UPDATE title=VALUES(title);

Save this as a UTF-8 file ending in .sql if you want to practise in your own empty lab database. This is demonstration data, not a WordPress migration file. It contains no DROP, DELETE or USE statement.

3. Open Import beside the correct database
Return to the database list and click Import in your destination row. Check the database name in the dialog title before selecting a file.

The dialog lists database archives stored on the server. Do not choose an unrelated backup simply because it appears in the list. The list can contain backups from other databases, including WordPress.

Click Upload from local → Select file, choose your .sql file and click Upload. Wait for the upload to finish. Uploading only transfers the file; it does not yet execute the SQL.

.jpg

sql-import-upload-20261013.jpg (Size: 62.43 KB / Downloads: 6)
The sample file is selected in the upload dialog. Complete the upload before starting Import.

The tested panel lists .sql, .zip, .gz, .tar.gz and .tgz support. When using an archive, check that it actually contains the intended SQL dump. For a file too large for browser upload, aaPanel's dialog suggests SFTP upload to /www/backup/database. Keep database backups outside the public website directory.

4. Start the import and read the warning
After upload, find the exact filename in the import list and click Import on that row. aaPanel asks: Database will be overwritten, continue?

Only confirm after checking the destination database, selected file and backup. Wait while aaPanel runs the background import. Avoid repeated clicks or starting several imports into the same database.

Closing the progress window is not evidence of success. The panel says the task continues in the background; use the log to check its result.

5. Read the import log
In the import dialog, click Show Logs and refresh if necessary. Read the output for the correct database and for errors. Our log reported Import status: Successful and Database recovery successful!

.jpg

sql-import-success-20261013.jpg (Size: 65.11 KB / Downloads: 7)
Actual log from the two-row lab import. A tiny sample completing quickly is not a speed estimate for large website databases.

If the log reports a SQL error, the database may already contain partially imported tables. Investigate that error before repeating the import. Do not assume a retry automatically undoes earlier statements.

6. Verify the tables and rows
Close the import dialog and open Tools in the destination database row. Confirm that the expected table names appear. Our new af_import_lesson_20261013 table showed two rows, and the old backup-test table was still present.

.jpg

sql-import-table-check-20261013.jpg (Size: 71.83 KB / Downloads: 8)
The new training table and the original test table are both visible. We only inspected this screen; Repair, Optimize and engine conversion were not needed.

For an exact data check, use your private database client or phpMyAdmin to run:

Code:

SELECT COUNT(*) AS imported_rows
FROM af_import_lesson_20261013;

SELECT id, title
FROM af_import_lesson_20261013
ORDER BY id;

For this sample, expect two rows and the two titles above. The screenshot's table row number is a useful panel check; use SELECT to verify exact counts for a real migration.

For a website migration, also update the application's database settings to the new database, check a real page and test any login or form that depends on it. Imported tables alone do not prove that the application is configured correctly.

Troubleshooting

The file is missing from the list: finish the upload, reopen Import and check the filename. An uploaded file and an imported database are separate steps.
Unknown collation or SQL syntax error: compare the source and destination database versions. Request a compatible export or review the failing SQL. Do not blindly replace every collation name in a production dump.
Access denied: check the database service and aaPanel's stored database credentials. Opening port 3306 to everyone does not fix a local importer authentication error.
Table already exists or duplicate entry: check whether you selected a populated destination or already ran the file. For a migration, use a separate empty database and retain the original backup.
Success message but missing data: check the selected database, expected table prefix and actual row contents. A structure-only export can create tables without restoring records.
Large import stalls or fails: inspect the log, available disk space and archive contents. Do not change PHP upload limits at random; browser upload and the panel's background database import are different stages.

Rollback and next steps
If an import damages existing data, stop changes and restore the correct pre-import backup through the database backup controls. Validate a restore in an isolated database before making a live application depend on it. See Back Up and Restore a Database in aaPanel for the recovery workflow.

aaPanel MySQL database documentation

Check MySQL Status and Error Logs in aaPanel]]> To import a MySQL or MariaDB database in aaPanel, open Databases, choose Import beside the correct database, upload your SQL file and confirm the import. Back up first, then verify the imported tables and data.

This walkthrough uses aaPanel's built-in importer. You do not need to expose phpMyAdmin publicly or open MySQL port 3306 to the internet.

Tested lab
Ubuntu 22.04 and aaPanel 8.0.7, tested on 13 October 2026. The database startup log reports MariaDB 10.11.10; the panel software button still displays the mariadb_10.11.6 label. The destination was our isolated adminsforum_lab tutorial database. We created a fresh backup, imported one sample table and verified that the panel lists it with a Row number of 2. The existing af_backup_check table remained present with one row. We did not import into the WordPress or webmail databases.

Before you begin

A running MySQL or MariaDB service and a database created in aaPanel.
A trusted .sql export containing database structure and/or data, not website files.
Enough free disk space for the upload, extracted archive and database.
A current backup of anything already in the destination database.

Code:

CREATE TABLE IF NOT EXISTS af_import_lesson_20261013 (
  id INT NOT NULL PRIMARY KEY,
  title VARCHAR(120) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO af_import_lesson_20261013 (id, title) VALUES
  (1, 'Welcome to AdminsForum'),
  (2, 'SQL import verified')
ON DUPLICATE KEY UPDATE title=VALUES(title);

Code:

SELECT COUNT(*) AS imported_rows
FROM af_import_lesson_20261013;

SELECT id, title
FROM af_import_lesson_20261013
ORDER BY id;

The file is missing from the list: finish the upload, reopen Import and check the filename. An uploaded file and an imported database are separate steps.
Unknown collation or SQL syntax error: compare the source and destination database versions. Request a compatible export or review the failing SQL. Do not blindly replace every collation name in a production dump.
Access denied: check the database service and aaPanel's stored database credentials. Opening port 3306 to everyone does not fix a local importer authentication error.
Table already exists or duplicate entry: check whether you selected a populated destination or already ran the file. For a migration, use a separate empty database and retain the original backup.
Success message but missing data: check the selected database, expected table prefix and actual row contents. A structure-only export can create tables without restoring records.
Large import stalls or fails: inspect the log, available disk space and archive contents. Do not change PHP upload limits at random; browser upload and the panel's background database import are different stages.

Rollback and next steps
If an import damages existing data, stop changes and restore the correct pre-import backup through the database backup controls. Validate a restore in an isolated database before making a live application depend on it. See Back Up and Restore a Database in aaPanel for the recovery workflow.

aaPanel MySQL database documentation

Check MySQL Status and Error Logs in aaPanel]]> <![CDATA[Create a Database and User in aaPanel Free Edition]]> https://adminsforum.com/Thread-guide-create-a-database-and-user-in-aapanel-free-edition Sun, 11 Oct 2026 02:33:33 +0800 DEV]]> https://adminsforum.com/Thread-guide-create-a-database-and-user-in-aapanel-free-edition Quick answer
Open Databases > MySQL > Add DB in aaPanel Free Edition. Enter a database name and a separate application user, keep utf8mb4, generate a strong password, and use Local server permission when the application runs on this VPS. Save, then verify the database appears in the list.

Before you start
MariaDB or MySQL must already be installed and running. aaPanel's MySQL tab also manages our MariaDB installation. Our lab website is created, but it does not yet have an application connected to this database.
Install MariaDB first.

1. Open Add DB
In the left menu, select Databases, then the MySQL tab and Add DB. Do not change the Root password for ordinary website setup.

2. Choose the database and user
Our example uses:

Code:

Database name: adminsforum_lab
Database user: adminsforum_lab
Character set: utf8mb4

Use a short, clear name for your own application. Keep a dedicated user for each database rather than connecting a website as root. utf8mb4 supports full Unicode, including emoji; check your application's requirements if it specifies a different character set.

3. Set the password and access
Generate a long, unique password and store it privately for the application's configuration. Never copy a tutorial password into a live website.
Choose Local server when the application and database are on this same VPS. The Add to field should identify LocalServer (127.0.0.1). Do not choose access from everyone or open port 3306 just to run a local website.
Click Confirm and wait for completion.

4. Verify the database list
Check the database name, username and Localhost location. Keep the password masked when sharing screenshots. Our verified result is shown below:

[Image: attachment.php?aid=15]

Our lab database was created through aaPanel's server-side database manager and then checked in the dashboard. A local connection using its dedicated user successfully selected adminsforum_lab. The user has privileges on that application database; we did not enable remote database access.

5. Use the details in your application
A typical same-server application needs:

Code:

Database host: localhost or 127.0.0.1 (follow the application requirements)
Database port: 3306
Database name: your database name
Database user: your application user
Database password: your private generated password

localhost can use a Unix socket while 127.0.0.1 uses TCP; use the connection method your application and database configuration support. This guide verifies the database account, not a completed CMS installation.

Troubleshooting
Access denied: Check the username, password and allowed host. Do not solve it by using root.
Unknown database: Check the exact database name in the panel.
Connection refused: Check that MariaDB/MySQL is running and listening for the connection method you selected.
No database in the list: Read the creation error before retrying; avoid creating several accounts blindly.

Next steps
Configure your website application with these credentials, then back up the database before importing data or making major changes. Website files and database backups are separate: both matter for a working restore.
Create a website in aaPanel Free Edition

Tested: 10 October 2026, aaPanel Free Edition 8.0.6 with MariaDB on Ubuntu 22.04. Original AdminsForum lab screenshot, with the database password masked.

.jpg

database-created-20261010.jpg (Size: 44.79 KB / Downloads: 10) ]]> Quick answer
Open Databases > MySQL > Add DB in aaPanel Free Edition. Enter a database name and a separate application user, keep utf8mb4, generate a strong password, and use Local server permission when the application runs on this VPS. Save, then verify the database appears in the list.

Before you start
MariaDB or MySQL must already be installed and running. aaPanel's MySQL tab also manages our MariaDB installation. Our lab website is created, but it does not yet have an application connected to this database.
Install MariaDB first.

1. Open Add DB
In the left menu, select Databases, then the MySQL tab and Add DB. Do not change the Root password for ordinary website setup.

2. Choose the database and user
Our example uses:

Code:

Database name: adminsforum_lab
Database user: adminsforum_lab
Character set: utf8mb4

Code:

Database host: localhost or 127.0.0.1 (follow the application requirements)
Database port: 3306
Database name: your database name
Database user: your application user
Database password: your private generated password

database-created-20261010.jpg (Size: 44.79 KB / Downloads: 10) ]]> <![CDATA[Install phpMyAdmin in aaPanel Free Edition]]> https://adminsforum.com/Thread-guide-install-phpmyadmin-in-aapanel-free-edition Sat, 10 Oct 2026 23:29:03 +0800 DEV]]> https://adminsforum.com/Thread-guide-install-phpmyadmin-in-aapanel-free-edition phpMyAdmin is a browser tool for working with MySQL or MariaDB databases. In this beginner guide, you will learn how to find its aaPanel installation, check its PHP runtime, understand its access settings, and prepare the correct database login.

Lab verification: Ubuntu 22.04.5, aaPanel Free Edition 8.0.6, phpMyAdmin 5.2 and MariaDB. Installation was completed with our original stack; management screens were checked again on 11 October 2026. phpMyAdmin uses PHP-84 while our website uses PHP 8.5. The panel's private launch currently requests an aaPanel vendor account login. Database browsing, import and export are not yet verified through that browser route.

Before you start: understand the three components

MariaDB/MySQL: The database server that stores your site's data.
PHP: The runtime that executes phpMyAdmin and PHP applications.
phpMyAdmin: A graphical tool that connects to the database server. It does not replace that server.

A website can use its database without phpMyAdmin being installed. Installing phpMyAdmin also does not create a WordPress database or a database user automatically.

You need: Access to your aaPanel, an installed database server, a compatible installed PHP runtime, and a database/user if you want to administer application data. Use a test database for practice. Back up an existing database before changing its contents.

Step 1 — Find phpMyAdmin in the App Store
1. Sign in to your own aaPanel.
2. Click App Store in the left menu.
3. Enter phpMyAdmin in the app search field and submit the search.
4. Locate the official phpMyAdmin row.

What you should see: Our lab shows phpMyAdmin 5.2, price Free, and Setting and Uninstall actions. These actions indicate that it is already installed. Do not uninstall it just to follow an installation guide.

AdminsForum lab screenshot — the installed app entry
[Image: phpmyadmin-app-entry-branded-20261011.png]

[Image: phpmyadmin-app-entry-branded-20261011.png]

Step 2 — Install only if the app is missing
If your row offers Install, select it, follow the panel's installation dialog, and wait until the task reports completion. Do not close or repeat the installation while its task is still running. Return to the app search and confirm that Setting is available.

Why this check matters: Starting a task is not the same as completing it. If installation fails, record the actual message and inspect the task log before trying again. The screenshot above shows the completed installation state; it does not show a fresh installation dialog.

Step 3 — Check the PHP runtime used by phpMyAdmin
1. Click Setting on the phpMyAdmin row.
2. Select PHP version in the management window.
3. Read the currently selected runtime.
4. If it is already a suitable installed PHP version, leave it unchanged.

What you should see: Our selection is PHP-84, meaning PHP 8.4. The screenshot also offers PHP-85. This guide does not switch phpMyAdmin to 8.5 or claim that this switch was tested.

AdminsForum lab screenshot — phpMyAdmin's own PHP selection
[Image: phpmyadmin-runtime-detail-branded-20261011.png]

[Image: phpmyadmin-runtime-detail-branded-20261011.png]

Why this matters: The website PHP selection and phpMyAdmin PHP selection are separate. Changing your website to PHP 8.5 does not mean phpMyAdmin must use 8.5. Static is not an appropriate runtime for a PHP application. If you deliberately change this selection, choose an installed compatible runtime, click Save, and test opening phpMyAdmin afterwards. Keep the previous working selection recorded so you can restore it.

Step 4 — Understand public access before enabling anything
1. In the same management window, open Service.
2. Find Enable public access.
3. Read the panel's explanation before changing the checkbox.

Our verified state: The checkbox is unchecked. In this version, the panel explains that authenticated panel access is separate from the public phpMyAdmin service. The numbered screenshot highlights the checkbox and explanation; the private access address has been hidden.

[Image: attachment.php?aid=10]

Why leave it off? You do not need an additional publicly reachable database-administration page just to learn the panel workflow. Do not enable public access or open its firewall port merely because an older tutorial uses a public URL. This guide does not change firewall rules or enable that service.

Step 5 — Locate the database you intend to manage
1. Close the phpMyAdmin settings window.
2. Open Databases from the left menu.
3. Find the application database by its name and remark.
4. Note the database name and associated username privately.
5. Use the row's phpMyAdmin action for the intended database.

If no application database exists, create it first using our database and user guide. Do not select a database just because it appears first in the list.

Step 6 — Try authenticated panel access
The database access dialog in our lab offers Password-free access and Public access. Choose Password-free access first while logged into the panel.

What happened in our test: aaPanel opened an aaPanel account registration/login prompt. This is the vendor account prompt, not a MySQL login. Until that account step is completed, we cannot demonstrate the database browsing screen through this route. If you encounter the same prompt, use your own account and follow its verification process. Do not paste account credentials into support posts.

If nothing opens, check whether the browser blocked a popup and retry the same authenticated action. If the vendor account step is completed but access still fails, record the exact response rather than switching to public access as an automatic workaround.

Step 7 — Know which password belongs where

aaPanel server login: Signs into the control panel installed on your VPS.
aaPanel vendor account: Signs into aaPanel's account service when a feature requests it.
MySQL/MariaDB user: Identifies the database account used by phpMyAdmin or your application.

If you reach a phpMyAdmin database-login form, it expects valid database credentials. The aaPanel server password is not a replacement for the database password. Prefer a user assigned to the application database for routine work rather than a database root account.

Troubleshooting: decide from the actual symptom

App does not appear installed: Check the installation task result and app list. Do not assume a clicked Install button completed successfully.
502 or blank page: Check phpMyAdmin's selected PHP runtime, the corresponding PHP service and relevant error logs. Check this runtime independently of the website's PHP version.
Vendor login prompt: Complete the account step. It does not mean the database password is wrong.
Database access denied: Check the database username, password, host and grants. Copy the error number after removing secrets.
Expected database missing: Confirm that it exists in aaPanel and that the database user has access to it. Stop before importing into another database.

Practice and completion checklist
Without changing any data, practise finding phpMyAdmin in the App Store, identifying its selected PHP runtime, locating your application's database, and explaining the difference between the three account types above.

You have completed setup preparation when the app is installed, its runtime is identified, the intended database/user exists, and the access route is understood. You have completed database access verification only after the intended database actually opens. Our browser access verification is still pending; screenshots of browsing, export and import will be added after successful tests.

Next lessons:

References: phpMyAdmin introduction and database user explanation; aaPanel App Store documentation. This walkthrough uses original AdminsForum lab captures and does not claim a completed video recording.

.jpg

phpmyadmin-annotated-20261010.jpg (Size: 53.66 KB / Downloads: 25) ]]> phpMyAdmin is a browser tool for working with MySQL or MariaDB databases. In this beginner guide, you will learn how to find its aaPanel installation, check its PHP runtime, understand its access settings, and prepare the correct database login.

Lab verification: Ubuntu 22.04.5, aaPanel Free Edition 8.0.6, phpMyAdmin 5.2 and MariaDB. Installation was completed with our original stack; management screens were checked again on 11 October 2026. phpMyAdmin uses PHP-84 while our website uses PHP 8.5. The panel's private launch currently requests an aaPanel vendor account login. Database browsing, import and export are not yet verified through that browser route.

Before you start: understand the three components

MariaDB/MySQL: The database server that stores your site's data.
PHP: The runtime that executes phpMyAdmin and PHP applications.
phpMyAdmin: A graphical tool that connects to the database server. It does not replace that server.

aaPanel server login: Signs into the control panel installed on your VPS.
aaPanel vendor account: Signs into aaPanel's account service when a feature requests it.
MySQL/MariaDB user: Identifies the database account used by phpMyAdmin or your application.

App does not appear installed: Check the installation task result and app list. Do not assume a clicked Install button completed successfully.
502 or blank page: Check phpMyAdmin's selected PHP runtime, the corresponding PHP service and relevant error logs. Check this runtime independently of the website's PHP version.
Vendor login prompt: Complete the account step. It does not mean the database password is wrong.
Database access denied: Check the database username, password, host and grants. Copy the error number after removing secrets.
Expected database missing: Confirm that it exists in aaPanel and that the database user has access to it. Stop before importing into another database.

phpmyadmin-annotated-20261010.jpg (Size: 53.66 KB / Downloads: 25) ]]> <![CDATA[Install MariaDB in aaPanel Free Edition]]> https://adminsforum.com/Thread-guide-install-mariadb-in-aapanel-free-edition Sat, 10 Oct 2026 23:27:49 +0800 DEV]]> https://adminsforum.com/Thread-guide-install-mariadb-in-aapanel-free-edition
Tested environment
Ubuntu 22.04.5 and aaPanel Free Edition 8.0.6. MariaDB was selected during our first-login stack installation. On 10 October 2026, the server reported MariaDB 10.11.10 and its database service was active. Some panel labels still use “MySQL” because this screen manages the compatible database server.

1. Select MariaDB
On a fresh panel, choose MariaDB in the database selector of the recommended stack dialog. If that dialog has already been dismissed, open App Store, locate the database server and use Install to choose an available MariaDB version. Follow the task until completion. If MariaDB is already installed, proceed to its settings.

Use one database server for this beginner setup. Do not uninstall an existing MySQL/MariaDB instance or replace its data directory to follow a fresh-install tutorial. Changing database engines on a populated server requires a separate backup and migration plan.

2. Verify the running service
Open App Store → Installed → MariaDB → Setting. Our service window is titled MySQL. In the screenshot, 1 marks the running state, 2 the service controls and 3 the Error log.
[Image: attachment.php?aid=9]

Use SSH to confirm the binary version and service status:

Code:

/www/server/mysql/bin/mysql --version
/etc/init.d/mysqld status

These checks do not require publishing or changing the database root password. We verified an active service on the lab. The version command alone only proves that the client binary is present.

3. Prepare for your application
Open Databases in aaPanel. Create a separate database and user for each application when you deploy it, and keep that user's permissions limited to its own database. Store the credentials privately in the application's configuration. Panel login credentials are not database credentials.

For a website on the same server, keep database access local. Opening port 3306 to the entire internet is unnecessary. Our lab firewall does not allow public access to that port.

Troubleshooting
If the service will not start, read the Error log and check available disk space. For an application's “access denied” error, check its database name, user, password and host. Do not reset the database root password or reinstall the server as the first response.

Install aaPanel Free Edition on Ubuntu 22.04
Web stack setup and tutorial series
Secure aaPanel Free Edition

Official aaPanel App Store documentation

.jpg

mariadb-annotated-20261010.jpg (Size: 52.81 KB / Downloads: 11) ]]>
Tested environment
Ubuntu 22.04.5 and aaPanel Free Edition 8.0.6. MariaDB was selected during our first-login stack installation. On 10 October 2026, the server reported MariaDB 10.11.10 and its database service was active. Some panel labels still use “MySQL” because this screen manages the compatible database server.

1. Select MariaDB
On a fresh panel, choose MariaDB in the database selector of the recommended stack dialog. If that dialog has already been dismissed, open App Store, locate the database server and use Install to choose an available MariaDB version. Follow the task until completion. If MariaDB is already installed, proceed to its settings.

Use one database server for this beginner setup. Do not uninstall an existing MySQL/MariaDB instance or replace its data directory to follow a fresh-install tutorial. Changing database engines on a populated server requires a separate backup and migration plan.

2. Verify the running service
Open App Store → Installed → MariaDB → Setting. Our service window is titled MySQL. In the screenshot, 1 marks the running state, 2 the service controls and 3 the Error log.
[Image: attachment.php?aid=9]

Use SSH to confirm the binary version and service status:

Code:

/www/server/mysql/bin/mysql --version
/etc/init.d/mysqld status

mariadb-annotated-20261010.jpg (Size: 52.81 KB / Downloads: 11) ]]>