DEV Community: Md.Shariful Islam

DevOps With Laravel: Queues and Workers in Production

Md.Shariful Islam — Sat, 17 May 2025 10:32:55 +0000

This article contains some useful tips on how to run queues and workers in production.

supervisor
The most important thing is that worker processes need to run all the time even if something goes wrong. Otherwise they'd be unreliable. For this reason we cannot just run php artisan queue:work on a production server as we do on a local machine. We need a program that supervises the worker process, restarts it if it fails, and potentially scales the number of processes.

The program we'll use is called supervisor. It's a process manager that runs in the background (daemon) and manages other processes such as queue:work.

First, let's review the configuration:

[program:worker]
command=php /var/www/html/posts/api/artisan queue:work --tries=3 --verbose --timeout=30 --sleep=3

We can define many "programs" such as queue:work. Each has a block in a file called supervisord.conf. Every program has a command option which defines the command that needs to be run. In this case, it's the queue:work but with the full artisan path.

As I said, it can scale up processes:

[program:worker]
command=php /var/www/html/posts/api/artisan queue:work --queue=default,notification --tries=3 --verbose --timeout=30 --sleep=3
numprocs=2

In this example, it'll start two separate worker processes. They both can pick jobs from the queue independently from each other. This is similar to when you open two terminal windows and start two queue:work processes on your local machine.

Supervisor will log the status of the processes. But if we run the same program (worker) in multiple instances it's a good practice to differentiate them with "serial numbers" in their name:

[program:worker]
command=php /var/www/html/posts/api/artisan queue:work --queue=default,notification --tries=3 --verbose --timeout=30 --sleep=3
numprocs=2
process_name=%(program_name)s_%(process_num)02d

%(program_name)s will be replaced with the name of the program (worker), and %(process_num)02d will be replaced with a two-digit number indicating the process number (e.g. 00, 01, 02). So when we run multiple processes from the same command we'll have logs like this:

Next we can configure ho supervisor supposed to start or restart the processes:

[program:worker]
command=php /var/www/html/posts/api/artisan queue:work --queue=default,notification --tries=3 --verbose --timeout=30 --sleep=3
numprocs=2
process_name=%(program_name)s_%(process_num)02d
autostart=true
autorestart=true

autostart=true tells supervisor to start the program automatically when it starts up. So when we start supervisor (for example when deploying a new version) it'll automatically start the workers.

autorestart=true tells supervisor to automatically restart the program if it crashes or exits. Worker processes usually take care of long-running heavy tasks, often communicating with 3rd party services. It's not uncommon that they crash for some reason. By setting autorestart=true we can be sure that they are always running.

Since we start two processes from queue:work it'd be great if we could treat them as one:

[program:worker]
command=php /var/www/html/posts/api/artisan queue:work --queue=default,notification --tries=3 --verbose --timeout=30 --sleep=3
numprocs=2
process_name=%(program_name)s_%(process_num)02d
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true

stopasgroup=true tells supervisor to stop all processes in the same process group as this one (queue:work) when it stops.

killasgroup=true tells supervisor to send a kill signal to all processes in the same process group as this one (queue:work) when it stops.

These option basically mean: stop/kill all subprocesses as well when the parent process (queue:work) stops/dies.

As I said, errors happen fairly often in queue worker, so it's a good practice to think about them:

[program:worker]
command=php /var/www/html/posts/api/artisan queue:work --queue=default,notification --tries=3 --verbose --timeout=30 --sleep=3
numprocs=2
process_name=%(program_name)s_%(process_num)02d
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
redirect_stderr=true
stdout_logfile=/var/log/supervisor/worker.log

redirect_stderr=true tells supervisor to redirect standard error output to the same place as standard output. We treat errors and info messages the same way.

stdout_logfile=/var/log/supervisor/worker.log tells supervisor where to write standard output for each process. Since we redirect stderr to stdout we'll have one log file to every message:

That was all the worker-specific configuration we need but supervisor itself also need some config in the same supervisord.conf file:

[supervisord]
logfile=/var/log/supervisor/supervisord.log
pidfile=/run/supervisord.pid

logfile=/var/log/supervisor/supervisord.log tells supervisor where to write its own log messages. This log tile contains information about the different programs and processes it manages. You can see the screenshot above.

pidfile=/run/supervisord.pid tells supervisor where to write its own process ID (PID) file. These files are usually located in the run directory:

By the way, PID files on Linux are similar to a MySQL or Redis database for us, web devs.

They are files that contain the process ID (PID) of a running program. They are usually created by daemons or other long-running processes to help manage the process.

When a daemon or other program starts up, it will create a PID file to store its own PID. This allows other programs (such as monitoring tools or control scripts) to easily find and manage the daemon. For example, a control script might read the PID file to determine if the daemon is running, and then send a signal to that PID to stop or restart the daemon.

And finally, we have one more config:

[supervisorctl]
serverurl=unix:///run/supervisor.sock

This section sets some options for the supervisorctl command-line tool. supervisorctl is used to control Supervisor. With this tool we can list the status of processes, reload the config, or restart processes easily. For example:

supervisorctl status

And finally, the serverurl=unix:///run/supervisor.sock config tells supervisorctl to connect to supervisor using a Unix socket. We've already used a Unix socket when we connected nginx to php-fpm. This is the same here. supervisorctl is "just" a command-line tool that provides better interaction with supervisor and its processes. It needs a way to send requests to supervisor.

5 levels of handling images in Laravel

Md.Shariful Islam — Sat, 17 May 2025 09:45:00 +0000

Image uploads are a common feature in most web applications. In this post, we'll walk through how to implement image uploads in Laravel, starting from the basics and gradually moving toward a full-featured solution. We'll cover resizing, image optimization, and UI enhancements and show how Spatie's packages and products can make the whole process easier, more efficient, and even a bit fun.

Level 1: Plain Laravel and the basics of image uploads
Let's start with a minimal example of how you can handle image uploads in Laravel using built-in functionality—no packages, just core features.

Set up the form First, you'll need a form in your Blade template that allows users to upload an image:

<form
    action="{{ route('upload') }}"
    method="POST"
    enctype="multipart/form-data"
>
    @csrf
    <input type="file" name="image">
    <button type="submit">Upload</button>
</form>

Handle the upload in a controller In your controller, you can handle the incoming file like this:

public function store(Request $request)
{
    $request->validate([
        'image' => 'required|image|max:2048', // max 2MB
    ]);

    $path = $request->file('image')->store('uploads', 'public');

    return back()
        ->with('success', 'Image uploaded successfully!')
        ->with('path', $path);
}

What you get
✅ A working upload flow
✅ Basic validation (image file, max size)
✅ Storage in the public disk

What's missing?
❌ No resizing or manipulation
❌ No optimization for performance
❌ No UI enhancements or previews
❌ No support for attaching images to models (like users or posts)

Level 2: Adding spatie/image
Now that basic uploads are working, let's say you want to resize or crop images before saving them. Laravel doesn't offer built-in tools for this, but Spatie's image package gives you an elegant and straightforward way to manipulate images.

Using the image package, we can extend our controller to add some image resizing:

public function store(Request $request)
{
    $request->validate([
        'image' => 'required|image|max:2048',
    ]);

    $uploadedFile = $request->file('image');

    // Store the original temporarily
    $path = $uploadedFile->store('temp');

    // Define the final path
    $finalPath = 'uploads/' . $uploadedFile->hashName();

    // Resize and save
    Image::load(storage_path('app/' . $path))
        ->width(800)
        ->save(storage_path('app/public/' . $finalPath));

    // Optionally remove the original
    Storage::delete($path);

    return back()
        ->with('success', 'Image resized and uploaded!')
        ->with('path', $finalPath);
}

Other things you can do
height(400) – constrain height
fit(800, 600) – resize to fit into a box
crop(width, height, x, y) – manually crop a section
blur(15) – apply blur
greyscale() – make the image black and white

What you get
✅ Image resizing and manipulation
✅ Clean, chainable syntax
✅ Works well for one-off or simple workflows

What's missing?
❌ No optimization (file size can still be large)
❌ Still manual—no model integration
❌ No UI integration

Next, let's fix the performance part by optimizing the images before we store them.

Level 3: Using spatie/image-optimizer to shrink file size
So far, we've got image uploads and resizing working, but the file size might still be much larger than it needs to be. Especially for web apps, keeping images small is critical for performance. That’s where spatie/image-optimizer comes in.

This package automatically optimizes images using well-known CLI tools under the hood (like jpegoptim, pngquant, and svgo)—without noticeably degrading quality.

Lucky for us image-optimizer seemlesly integrates with the image package so we only need to add one line to our controller:

public function store(Request $request)
{
    ...

    // Resize and save
    Image::load(storage_path('app/' . $path))
        ->width(800)
        ->optimize() // This will optimize the image before saving.
        ->save(storage_path('app/public/' . $finalPath));

    ...
}

What you get
✅ Automatically smaller file sizes
✅ No visual quality loss
✅ Works with any image manipulation flow

What's missing?
❌ Still no model integration
❌ No UI integration

Level 4: Using spatie/laravel-medialibrary
Spatie's laravel-medialibrary is a powerful package that takes image uploads to the next level. It allows you to associate uploaded files (not just images!) with Eloquent models, generate automatic conversions, handle storage cleanly, and much more.

Installation
You can find the full installation instructions for laravel-media library.
Usage
Once installed, we can create a model, in this case a post, and simply attach our uploaded image to it:

public function store(Request $request)
{
    $request->validate([
        'title' => 'required',
        'image' => 'required|image|max:2048',
    ]);

    $post = Post::create([
        'title' => $request->input('title'),
    ]);

    $post->addMediaFromRequest('image')
         ->toMediaCollection('featured');

    return redirect()->back()
        ->with('success', 'Post created and image uploaded!');
}

What you get
✅ Images are attached to models
✅ Automatic conversions (thumbs, responsive, etc.)
✅ Clean file storage
✅ Support for collections and multiple images

What's missing?
❌ No user-friendly upload UI
❌ Upload experience is still native HTML form elements (no previews, drag & drop)

Level 5: Using Media Library Pro for a polished UI uxperience
Once you've got laravel-medialibrary set up, Media Library Pro takes things to a whole new level. It's a commercial add-on by Spatie that provides drop-in Vue and Livewire components for a modern, user-friendly image upload experience—with previews, drag & drop, progress bars, reordering, and more.

💡 Media Library Pro is a paid product, but it will save you hours of frontend work and integrates tightly with Laravel.

Media Library Pro is available for all types of frontend: Blade, Livewire, React and Vue. Installation instructions can be found in our extensive documentation.

Once installed, you can add the component to your frontend code. Here's a Blade example:

<form method="post">
    <x-media-library-attachment name= "image" rules= "mimes:png,jpeg,pdf"/>

    <button>Submit</button>
</form

And in our controller you can handle the upload like this:

public function store(Request $request)
{
    $request->validate([
        'title' => 'required',
        'image' => 'required|image|max:2048',
    ]);

    $post = Post::create([
        'title' => $request->input('title'),
    ]);

    $post->addFromMediaLibraryRequest('image')
         ->toMediaCollection('featured');

    return redirect()->back()
        ->with('success', 'Post created and image uploaded!');
}

Which should result in a beautiful, functional upload component:

What you get
✅ Modern, reactive UI components
✅ Deep integration with your models
✅ Preview, progress, reordering out of the box
✅ Built and maintained by the creators of Media Library

What's missing?
🙌 Nothing!

Conclusion
Whether you stick with Laravel's built-in tools or go all-in with Media Library Pro, how far you take your image upload implementation depends on your project's needs. The Spatie packages and products at every level offer well-crafted solutions to help you build a clean, efficient, and scalable solution.

15 Laravel Security Best Practices in 2025

Md.Shariful Islam — Sat, 17 May 2025 06:52:12 +0000

Laravel is one of the most popular PHP frameworks, and for good reason—it's elegant, expressive, and comes with many built-in security features. But just because Laravel provides the tools doesn’t mean you’re automatically safe.

Whether you're building an MVP or maintaining a large-scale application, security must be a priority.

Here are 15 Laravel security best practices every developer should follow in 2025:

🔐 1. Keep Laravel and Dependencies Updated
Always keep Laravel, its dependencies, and PHP up to date.
Laravel releases often include security patches and improvements.

.
🔒 2. Prevent SQL Injection
Laravel's Eloquent ORM and query builder automatically use prepared statements.

✅ Safe:

$users = DB::table('users')->where('email', $email)->get();

❌ Avoid:

DB::select("SELECT * FROM users WHERE email = '$email'")

🧼 3. Avoid Cross-Site Scripting (XSS)

Escape all output using Blade syntax:

{{ $user->name }}  // Escapes HTML output

🛡️ 4. CSRF Protection
Laravel includes CSRF protection middleware by default. Just don’t forget to include @csrf in your forms.

<form method="POST" action="/submit">
    @csrf
    <!-- form inputs -->
</form>

👥 5. Use Built-In Auth & Authorization
Leverage Laravel Breeze, Fortify, or Jetstream. Use Gates and Policies to control access.

$this->authorize('update', $post);

🗝️ 6. Store Passwords Securely
Never store plain text passwords. Laravel uses Bcrypt or Argon2 by default.

Hash::make('supersecret');

🔑 7. Secure Your .env and Configs
Never commit .env files.
Set APP_DEBUG=false in production.
Use environment variables for credentials.
🔐 8. Force HTTPS
Force SSL in production.

// AppServiceProvider.php
use Illuminate\Support\Facades\URL;

public function boot()
{
    if (app()->environment('production')) {
        URL::forceScheme('https');
    }
}

🧾 9. Validate and Sanitize File Uploads
Validate file size and type.
Avoid storing files in /public if you don’t need public access.
Sanitize filenames.

$request->validate([
    'avatar' => 'required|file|mimes:jpg,jpeg,png|max:2048',
]);

🍪 10. Secure Cookies & Sessions
In config/session.php, set secure defaults:

'secure' => env('SESSION_SECURE_COOKIE', true),
'http_only' => true,
'same_site' => 'lax',

📈 11. Rate Limiting
Prevent brute force attacks using Laravel's rate limiter.

Route::middleware(['throttle:60,1'])->group(function () {
    // Protected routes
});

🚫 12. Avoid Mass Assignment Vulnerabilities
Use $fillable or $guarded in your Eloquent models.

protected $fillable = ['name', 'email'];

📜 13. Monitor and Log Suspicious Activity
Use Laravel logging + services like Sentry, Bugsnag, or LogRocket

Log::warning('Suspicious login attempt', ['email' => $request->email]);

📦 14. Vet Third-Party Packages
Install only packages you trust. Check for:

Active maintainers
Regular updates
Community adoption
🔍 15. Run Regular Security Audits
Use tools like

🔍 Larastan
🔐 Laravel Security Checker
🧪 PHPStan
✅ Conclusion
Security isn’t a one-time task. It's a habit.

With Laravel, you already have a strong foundation—just make sure you're using it right.

Step by Step Guide Laravel CI/CD with GitHub Actions

Md.Shariful Islam — Sat, 17 May 2025 06:30:00 +0000

What is GitHub Actions?

GitHub Actions is a free automation tool that is built into GitHub. It lets you run scripts and commands automatically when certain events happen in your repository, like pushing code or opening a pull request.

Workflow Overview
Our workflow will:

Run on every push or pull request to the main or dev branches.
Set up a MySQL database for testing.
Install PHP and all required extensions.
Cache Composer dependencies for faster builds.
Install your Laravel app’s dependencies.
Run static analysis and code quality checks.
Run your automated tests.
Let’s break down each step!

Workflow Triggers

on:
  push:
    branches: ["main", "dev"]
  pull_request:
    branches: ["main", "dev"]
This tells GitHub to run the workflow every time you push code or open a pull request to the main or dev branches.

Define the Job and Environment

jobs:
  tests:
    runs-on: ubuntu-latest
We define a job called tests that runs on the latest Ubuntu Linux environment provided by GitHub.

Set Up MySQL Database

services:
  mysql:
    image: mysql:8.0
    ports:
      - 3306:3306
    env:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: test_db
    options: --health-cmd="mysqladmin ping"
We spin up a MySQL 8.0 database in Docker, set the root password, and create a database called test_db. The health check ensures MySQL is ready before tests run.

Checkout Your Code

- uses: actions/checkout@v4
This step pulls your repository’s code into the workflow environment so the next steps can work with it.

Setup PHP with All Laravel Extensions

- name: Setup PHP with PECL extension
  uses: shivammathur/setup-php@v2
  with:
    php-version: '8.4'
    extensions: mbstring, bcmath, ctype, fileinfo, json, tokenizer, xml, pdo, pdo_mysql, openssl, curl, zip, imagick, swoole

We install PHP 8.4 and all the extensions Laravel and its ecosystem commonly need. This ensures your app runs just like it would in production.

Cache Composer Dependencies

- name: Cache Composer dependencies
  uses: actions/cache@v4
  with:
    path: vendor
    key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
    restore-keys: |
      ${{ runner.os }}-composer-
This is “smart caching.” If your dependencies haven’t changed, Composer can skip downloading and installing them, making your workflow much faster.

Copy the CI Environment File

- name: Copy .env file
  run: |
    cp .env.ci .env
We copy a special .env.ci file to .env. This file should contain settings for your test database and other CI-specific configs.

Install Composer Dependencies

- name: Install dependencies
  run: |
    composer install -q --no-ansi --no-interaction --no-scripts --no-progress
We install all PHP dependencies your Laravel app needs, using flags to make the process faster and quieter.

Generate Laravel Application Key

- name: Generate application key
  run: |
    php artisan key:generate
Laravel needs an application key for encryption and sessions. This command generates it.

Set Directory Permissions

- name: Directory permissions
  run: |
    sudo chown -R $USER:$USER storage bootstrap/cache
    chmod -R 775 storage bootstrap/cache
Laravel needs write access to storage and bootstrap/cache for logs and cache files. This step ensures the permissions are correct.

Run Static Analysis with PHPStan

- name: phpstan
  run: |
    ./vendor/bin/phpstan analyse --level=5 --memory-limit=1G
PHPStan checks your code for bugs and potential issues without running it. This helps you catch problems early.

Run Code Quality Checks with PHP Insights

- name: phpinsights
  run: |
    php artisan insights --no-interaction \
    --min-quality=90 --min-complexity=90 \
    --min-architecture=90 --min-style=90 \
    --ansi --format=github-action
PHP Insights analyzes your code for quality, complexity, architecture, and style. The workflow enforces minimum scores for each metric.

Show Database Configuration

- name: Show DB config
  run: |
    grep DB_ .env
This step prints out the database settings being used, so you can verify your tests are running against the correct database.

Run Your Tests!

- name: Run tests
  run: |
    php artisan test
Finally, we run all your Laravel tests. These tests will use the MySQL test database you set up earlier.

Conclusion
With this workflow, every push or pull request is automatically tested in a fresh environment, with a real database, and all the tools you need for code quality. This helps you catch bugs early, maintain high standards, and move faster as a team.

Tip:

Make sure your .env.ci file is committed and contains the correct database settings for CI!

SOLID in Laravel.

Md.Shariful Islam — Wed, 07 May 2025 07:15:20 +0000

SOLID in short

1/ S

(Single Responsibility Principle)

A class should have only one job.
Keep controllers and models thin.
Move logic to services or traits.

2/ O

(Open/Closed Principle)

Extend behavior without modifying existing code
Use interfaces or abstract classes.
Avoid editing core logic for new features.

3/ L

(Liskov Substitution Principle)

Subclasses must work like their parent class.
Methods should keep expected behavior.
Avoid overriding with incompatible logic.

4/ I

(Interface Segregation Principle)

Interfaces should be small and specific.
No class should depend on unused methods.
Split large interfaces into smaller ones.

5/ D

(Dependency Inversion Principle)

Depend on interfaces, not concrete classes.
Use Laravel’s Service Container for injection.
- use Laravel’s Service Container

Common Laravel Mistakes That Violate SOLID

Fat controllers violating SRP.
Too much logic in Models
Direct Database Queries in Controllers (Violates SRP & DIP)
Not using contracts/interfaces, leading to tight coupling (DIP).

Laravel Tools & Features That Support SOLID

Service Providers & Dependency Injection (DIP).
Custom Requests
Repositories & Interfaces (OCP, LSP).
Middleware for separating concerns (SRP).
Policies & Gates for clean authorization logic (SRP).

ডাটাবেজে Collation কেন প্রয়োজন ?

Md.Shariful Islam — Wed, 29 Jan 2025 07:02:47 +0000

কোলেশন হলো MySQL-এ একটি নিয়মের সেট যা নির্ধারণ করে কিভাবে ডেটা সাজানো (sort) এবং তুলনা (compare) করা হবে। এটি মূলত ক্যারেক্টার এনকোডিং (character encoding) এবং স্ট্রিং অপারেশনের জন্য নিয়ম তৈরি করে, যেমন:

কেস সেনসিটিভিটি (বড় হাতের অক্ষর vs ছোট হাতের অক্ষর, যেমন: A vs a)

অ্যাকসেন্ট সেনসিটিভিটি (যেমন: é vs e)

ভাষাভিত্তিক সাজানোর নিয়ম (যেমন: জার্মান ভাষায় ä কে a-এর কাছাকাছি সাজানো হয়, কিন্তু সুইডিশ ভাষায় z-এর পরে)।

এটি ক্যারেক্টার সেট (character set)-এর সাথে যুক্ত, যা ডাটাবেসে স্টোর করা যায় এমন ক্যারেক্টার (অক্ষর) নির্ধারণ করে।

কোলেশন কেন প্রয়োজন?
১. ডেটা সাজানো (Sorting):

কোলেশন নির্ধারণ করে ডেটা কোন অর্ডারে দেখানো হবে। যেমন: utf8mb4_general_ci কোলেশনে Apple এবং apple একই মনে করা হয় (কেস-ইনসেনসিটিভ), কিন্তু utf8mb4_bin-এ এরা ভিন্ন।

২. স্ট্রিং তুলনা (Comparison):

WHERE ক্লজ বা JOIN-এ স্ট্রিং তুলনার সময় কোলেশন নিয়ম প্রয়োগ হয়। যেমন: 'café' = 'cafe' সত্যি হবে কি না তা কোলেশন উপর নির্ভর করে।

৩. সার্চিংয়ের সঠিকতা:

কোলেশন অনুযায়ী সার্চ রেজাল্ট পরিবর্তিত হয়। যেমন: LIKE '%cat%' কুয়েরিতে Cat বা CAT পাওয়া যাবে কি না তা কোলেশন ঠিক করে।

৪. ভাষা সমর্থন:

বিভিন্ন ভাষার ক্যারেক্টার সঠিকভাবে সাজাতে বা তুলনায় কোলেশন ব্যবহৃত হয়। যেমন: স্প্যানিশ ñ বা জার্মান ß-এর জন্য আলাদা নিয়ম।

৫. ডেটা সামঞ্জস্যতা:

সব অপারেশনে (সাজানো, তুলনা, সার্চ) একই নিয়ম প্রয়োগ করে ডেটার ধারাবাহিকতা বজায় রাখে।

কোলেশনের উদাহরণ
utf8mb4_general_ci:

কেস-ইনসেনসিটিভ, সাধারণ ইউনিকোড সাপোর্ট।

A = a, É = E হিসেব করা হয়।

utf8mb4_bin:

বাইনারি তুলনা (কেস-সেনসিটিভ)।

A ≠ a, É ≠ E।

utf8mb4_unicode_ci:

ইউনিকোডের সম্পূর্ণ সাপোর্ট, বহুভাষার জন্য উপযুক্ত।

কোলেশন কিভাবে সেট করবেন?
১. ডাটাবেস লেভেলে:

sql
Copy
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
২. টেবিল লেভেলে:

sql
Copy
CREATE TABLE mytable (
id INT,
name VARCHAR(255)
) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
৩. কোলাম লেভেলে:

sql
Copy
CREATE TABLE mytable (
id INT,
name VARCHAR(255) COLLATE utf8mb4_bin
);
কোন কোলেশন বেছে নেবেন?
কেস সেনসিটিভিটি: _ci (কেস-ইনসেনসিটিভ) বা _bin (কেস-সেনসিটিভ) নির্বাচন করুন।

ভাষার প্রয়োজন: বহুভাষার ডেটার জন্য utf8mb4_unicode_ci ভালো।

পারফরম্যান্স: utf8mb4_general_ci দ্রুত, কিন্তু unicode_ci বেশি অ্যাকুরেট।

সতর্কতা
কোলেশন মিসম্যাচ: টেবিল জয়েন বা তুলনায় ভুল এড়াতে সব টেবিল/কোলামে একই কোলেশন ব্যবহার করুন।

ইনডেক্সিং: কোলেশন পরিবর্তন করলে ইনডেক্স পুনরায় বিল্ড করতে হতে পারে।

সংক্ষেপে
কোলেশন MySQL-এ ডেটার সাজানো, তুলনা এবং সার্চিংকে প্রভাবিত করে। অ্যাপ্লিকেশনের ভাষা, কেস সেনসিটিভিটি এবং পারফরম্যান্সের ভিত্তিতে সঠিক কোলেশন বেছে নিন!