MySQL
قاعدة بيانات مفتوحة شائعة جداً، خصوصاً خلف المواقع والتطبيقات. كثير من البيانات التشغيلية تعيش فيها.
قاعدة بيانات مفتوحة شائعة جداً، خصوصاً خلف المواقع والتطبيقات. كثير من البيانات التشغيلية تعيش فيها.
ماذا يحمل MySQL، ولماذا يهمّ ذلك هنا
هذه القاعدة تقف خلف عدد كبير من المواقع والتطبيقات الداخلية، وبياناتها تشغيلية بطبيعتها: طلبات، ومستخدمون، وحركات، وسجلات.
والأسئلة عنها يومية ومتكررة، وأغلبها بسيط: كم، ومتى، وما الحالة. أسئلة لا تحتاج تحليلاً بل قراءة.
والقواعد نفسها: نطاق صريح، وقراءة فقط، وحساب خدمة منفصل، وترجمة المخرَج إلى لغة مفهومة لا عرض صفوف كما هي.
- بيانات التطبيق — كل ما يسجّله النظام المبني عليها.
- سجلات المستخدمين والعملاء — حيث يحفظها التطبيق.
- سجل الحركات — الأحداث والحالات عبر الوقت.
- الجداول المرجعية — القوائم التي يعتمد عليها التطبيق في عمله.
- العروض — ما عُرِّف منها مسبقاً، وهي الطريقة الموصى بها لتحديد ما يُقرأ.
أسئلة يجيب عنها إلبي من قاعدة MySQL
ما حالة هذا الطلب؟
الحالة من العرض المخصّص لها، بجملة مفهومة.
كم عدد كذا اليوم؟
إحصاء ضمن النطاق المسموح.
متى سُجّل هذا؟
التاريخ المسجّل كما هو.
هل هذا موجود؟
بحث ضمن النطاق المسموح.
ما آخر حركة؟
الحقل المحدد ضمن النطاق.
من أنشأ هذا؟
الحقل المسجّل حيث يكون عرضه مناسباً.
كيف يستعلم إلبي من MySQL دون المساس بالإنتاج
- حساب مربوط بمضيفالحسابات في MySQL تُعرَّف بصيغة «مستخدم على مضيف»، فيمكن إنشاء حساب المساعد بحيث لا يقبل الاتصال إلا من العنوان الذي يستخدمه الربط. وله كلمة مرور أو شهادة خاصة به، ويمكن بخيار REQUIRE SSL اشتراط تشفير كل جلسة.
- SELECT على العروض، ولا شيء غيرهايُمنح الحساب صلاحية SELECT على عدد قليل من العروض (views) المسمّاة، ولا يحمل أي صلاحية عامة على الخادم. ولأن العرض في MySQL يعمل افتراضاً بصلاحيات من عرّفه (definer)، يستطيع الحساب القراءة عبر العرض دون أي وصول إلى الجداول التي تحته.
- نسخة قراءة لا القاعدة الرئيسيةحيث يوجد نسخ متماثل (replication)، يقرأ الربط من نسخة مضبوطة على read_only، فلا ينافس استعلام بطيء التطبيقَ على القاعدة الرئيسية. ونسخ MariaDB تعمل بالطريقة نفسها لهذا الغرض.
- عبارات ثابتة بمعاملاتكل سؤال مدعوم عبارة مُعدّة مسبقاً (prepared statement) تُكتب أثناء التشغيل، فيها مواضع للمرجع أو التاريخ الذي يقدمه السائل. المساعد يملأ القيم ولا يؤلف SQL، فلا توجد صياغة لسؤال تنتج استعلاماً غير مخطط له.
- حدود للوقت والحجمحدّ زمني للعبارة (max_execution_time في MySQL وmax_statement_time في MariaDB) مع حدود الموارد لكل حساب يمنعان أي استعلام منفلت من الاستمرار. ومن يسأل عن طلب واحد لا يحتاج أكثر من صفوف قليلة.
- الصفوف تصبح جملاًرموز الحالة والأعلام والمفاتيح الأجنبية تتحول إلى عربية أو إنجليزية مفهومة، والعرض هو المكان الذي تُعالج فيه اختيارات التخزين المربكة — تواريخ محفوظة كنص، وصفوف «محذوفة» ما زالت موجودة بعلامة — فلا يُترك شيء للتخمين.
الصلاحيات والمضيف وما يبقى ملككم
الوصول قراءة فقط، وينبغي أن يبقى كذلك. صلاحية SELECT على عروض مسمّاة هي كل ما يُمنح؛ والكتابة مكانها التطبيق الذي يملك البيانات ويطبّق قواعدها.
والعروض ترسم الحد الأقصى لما يستطيع الحساب قراءته. وأيّ تلك الإجابات يصل إلى الشخص يتبع هويته في نظام الدخول لديكم، فلا يُجاب العميل إلا عن سجلاته هو.
وبيانات الاعتماد حساب مخصّص على مضيف ثابت، بكلمة مرور أو شهادة تضبطونها. ALTER USER يدوّرها وDROP USER يلغي الحساب، وكلاهما من جهتكم دون تدخل منا.
والصفوف التي يعيدها الاستعلام تُستخدم للرد الذي جُلبت من أجله. ويُتلف محتوى الرسائل خلال 24 ساعة، وفي أغلب الأحوال عند انتهاء المحادثة، ولا يُرسل شيء إلى خدمة ذكاء اصطناعي خارجية.
وللتدقيق، سجل الاستعلامات العام (general query log) يسجّل كل شيء لكنه ثقيل على بيئة الإنتاج؛ أما إضافة التدقيق في MariaDB أو MySQL Enterprise Audit فتستطيع تسجيل نشاط حساب واحد بعينه على خادمكم.
وإن تعذّر الوصول إلى القاعدة أو رفضت الحساب، يقول المساعد ذلك ويعرض التحويل إلى موظف، ولا يعود إلى جواب سابق أو إلى التخمين.
ما الذي يحلّ محلّه ربط MySQL
ما يحلّ محلّه هذا هو رسالة إلى المطوّر تسأل عن رقم. وهي مقاطعة صغيرة تتكرر كثيراً، وتكلفتها الحقيقية ليست في الدقائق بل في قطع التركيز.
والنتيجة أن الفرق التقنية تقضي جزءاً معتبراً من يومها في الإجابة عن أسئلة لا تحتاج خبرتها، وأن السائلين ينتظرون بلا داعٍ.
والاتصال بنطاق محدد يزيل هذه الفئة كاملة، ويترك الفريق للعمل الذي وُظّف من أجله.
من يستفيد أكثر من ربط MySQL
المواقع والتطبيقات
أشهر موضع لهذه القاعدة.
التجارة الإلكترونية
الطلبات والحركات التشغيلية.
الأنظمة الداخلية
بيانات بلا واجهة سهلة.
التقنية
تقليل المقاطعات المتكررة.
العمليات
أرقام يومية دون انتظار.
الإدارة
أرقام التطبيق اليومية دون انتظار مطوّر.
كيف تستفيدون فعلاً من تطبيق MySQL قديم
الوضع المعتاد مع MySQL تطبيق يعمل، لكن شاشاته لا تغطي إلا جزءاً مما تستطيع بياناته الإجابة عنه. ابدأوا بقائمة الأسئلة التي يحملها الموظفون اليوم إلى من ما زال يفهم بنية القاعدة — مطوّر أو مورّد خارجي في الغالب — وعدّوا تكرار كل منها. الأكثر تكراراً يصبح أول العروض.
وتأخر النسخة (replica lag) يهمّ في الإجابات الحساسة للوقت. النسخة تتبع القاعدة الرئيسية عن قرب عادة، لكنها قد تتأخر تحت الضغط، وMySQL يبيّن هذا التأخر على النسخة نفسها. فلسؤال مثل «هل وصلت دفعتي؟» يستحق التأخرُ الفحص قبل الإجابة، أما مجاميع الشهر الماضي فلا يؤثر فيها.
والنص العربي يحتاج نظرة قبل الإطلاق. بعض التطبيقات القديمة خزّنت العربية في أعمدة معرّفة بمجموعة محارف أوروبية غربية، فتعود حروفاً مشوّهة حتى يُعالج الترميز. واكتشاف ذلك في الاختبار أرخص بكثير من أن يكتشفه عميل.
ما الذي يتطلبه ربط MySQL أو MariaDB
- اختيار الأسئلة والمفتاح وراء كل منهالكل سؤال، حدّدوا الجداول المعنية والمفتاح الذي سيقدمه السائل — رقم طلب أو مرجع حساب أو بريد إلكتروني — وتأكدوا أن عمود المفتاح مفهرس. السؤال الذي لا مفتاح موثوقاً له ليس جاهزاً بعد.
- كتابة العروضأنشئوا عرضاً لكل سؤال، أو لكل مجموعة صغيرة من الأسئلة، لا يكشف إلا الأعمدة التي يحتاجها الجواب. واجعلوها في قاعدة منفصلة أو بأسماء واضحة، لتسهل مراجعتها ويصعب خلطها بكائنات التطبيق.
- إنشاء الحساب ومنح SELECTCREATE USER على المضيف الذي يتصل منه الربط، وGRANT SELECT على تلك العروض وحدها، مع اشتراط TLS وضبط حدود الموارد. وينبغي أن تتسع نتيجة SHOW GRANTS للحساب في شاشة واحدة بسهولة.
- توجيهه إلى نسخة قراءةإن وُجدت نسخة قراءة فاستخدموها. وإن لم توجد، فقرّروا هل الاستعلامات خفيفة بما يكفي للقاعدة الرئيسية، أم أن هذا وقت إضافة نسخة.
- الاختبار بمدخلات صعبةمراجع غير موجودة، ومرجع يخص شخصاً آخر، وأسماء عربية مكتوبة بأكثر من طريقة، وطلب يعيد صفوفاً أكثر بكثير مما ينبغي. ينبغي أن ينتهي كلٌّ منها بجواب واضح أو بموظف.
- الإطلاق على عروض قليلةابدأوا بعدد قليل من العروض، وأضيفوا غيرها حين تكشف الأسئلة الحقيقية مواضع النقص، مع مراجعة كل عرض جديد بعناية الأول نفسها.
البيانات الشخصية في جداول تطبيقات MySQL
قواعد بيانات التطبيقات تحفظ البيانات الشخصية عادة في الجداول نفسها مع كل شيء آخر: الأسماء وأرقام الجوال وأرقام الهوية بجانب بنود الطلبات. وبموجب نظام حماية البيانات الشخصية في المملكة، العرض هو المكان الطبيعي لتقليل البيانات، لأن الأعمدة التي لا يستخدمها السؤال يمكن إخراجها منه تماماً.
وموقع البيانات يحدده مكان تشغيل القاعدة — خادمكم أنتم، أو مزوّد استضافة، أو خدمة سحابية مُدارة في منطقة اخترتموها — والربط لا يغيّر ذلك. دوّنوه مع قائمة العروض ليرى المراجع أين توجد البيانات وأيّ الأعمدة بالضبط يمكن قراءتها.
وقائمة الصلاحيات هي الجواب المختصر عن سؤال «ماذا يستطيع أن يرى؟». وإبقاؤها قصيرة بحيث تُقرأ بصوت مسموع إجراء حوكمة قائم بذاته.
كيف يُوصل عادةً إلى بيانات MySQL، وما ثمن كل طريق
الطريق الأشيع أداة إدارة قواعد بيانات مثل phpMyAdmin أو Adminer، تُسلَّم للقلة القادرين على استخدامها. وهي تجيب عن أي شيء، وهذه هي المشكلة: الوصول واسع، والجواب يتوقف على من يجلس أمام لوحة المفاتيح.
وأدوات ذكاء الأعمال المتصلة بنسخة قراءة تخدم التقارير المتكررة جيداً، وكثير من بيئات MySQL فيها واحدة منها. وهي تناسب من يريد لوحة مؤشرات، ولا تناسب بالقدر نفسه عميلاً يسأل عن طلب واحد بالعربية خارج أوقات الدوام.
وبعض الفرق تضع واجهة برمجية داخلية صغيرة أمام القاعدة لكل سؤال جديد. وهو الخيار الأكثر انضباطاً والأبطأ في الوقت نفسه، لأن كل سؤال يصبح مهمة تطوير.
والخطأ المتكرر حساب يملك SELECT على المخطط كله، أو إعادة استخدام بيانات اعتماد التطبيق نفسه لأنها كانت في المتناول. وكلاهما يحوّل استعلاماً محدوداً إلى نسخة من صلاحيات التطبيق الكاملة.
ما الذي تراه المؤسسات عادة
أسئلة متكررة عن ربط MySQL
لا. الحساب لا يملك غير SELECT على عروض محددة، والكتابة تبقى للتطبيق الذي يملك البيانات.
لا. النطاق صريح، ونوصي بطبقة عرض.
الاستعلامات محدودة النطاق، ويمكن توجيهها إلى نسخة قراءة إن كانت لديكم. والحمل يُقاس قبل الإطلاق.
ما تسمحون به فقط. الأعمدة الحساسة لا تدخل العرض أصلاً، فلا يستطيع الحساب قراءتها.
الصلاحية تُربط بهوية السائل، ويُصمَّم هذا الربط صراحة لأن القاعدة لا تحمله.
بإيقاف حساب الخدمة المنفصل.