Optimiser cette requête pour 1000 patients dans la table des patients

SELECT patientid, firstname,lastname,mobilephone,email, FORMAT( COALESCE(
    ( SELECT SUM(ammount)-SUM((ammount * (discount/100))) 
    FROM invoice 
    INNER JOIN patient
    ON invoice.patientid = patient.patientid 
    and invoicednumber >0) - 
    ( SELECT SUM(ammount) 
      FROM payment 
      INNER JOIN patient 
      ON payment.patientid = patient.patientid ),0),0) AS answer, 
    DATE_FORMAT(( SELECT max(paymentdate) 
                  FROM payment 
                  INNER JOIN patient 
                  ON payment.patientid = patient.patientid ),'%d-%m-%Y') As lastpaymentdate 
from patient WHERE 1 
This will work more faster!!!!  Try it and let me know  UPDATE
I have replace WHERE clause with inner join which will help to get data in quick time.
I would also add that if indexes are not there on primary key then do add.  

Bien qu'il s'agisse d'un exemple, votre clause WHERE renvoie essentiellement TOUS les patients. Ce qui tue probablement vos performances, c'est que vous faites 3 requêtes corrélées dans vos listes de champs en interrogeant à chaque fois pour chaque personne. Une fois pour la facture et deux fois pour les paiements.

Au lieu de cela, j'ai restructuré la requête basée sur PreQuery LEFT-JOINs aux tables de factures et de paiements. Si vous regardez, le tableau de la facture est pré-résumé avec un GROUP BY chaque ID patient. De même, par tableau des paiements, GROUP BY chaque ID patient. Ainsi, dans le pire des cas, chaque sous-requête renverra au PLUS un enregistrement pour un patient donné donnant le total de toutes les factures et les remises respectives. Pour les paiements, une somme de tous les paiements ET la date la plus récente.

Donc, avec ceci commençant par la table patient, je peux joindre à gauche sur l'ID patient commun, vous pouvez voir les valeurs récapitulatives simplifiées à la sortie finale et sera applicable à tous les patients. Oui, vous pouvez toujours ajouter des critères WHERE pour restreindre davantage, mais les performances devraient être nettement meilleures.

SELECT 
        p.patientid, 
        p.firstname, 
        p.lastname, 
        p.mobilephone, 
        p.email,
        coalesce( PatInv.JustSumOfAmount - PatInv.DiscountedAmounts, 0 )
            - coalesce( PatPay.PaidAmounts, 0 ) Answer,
        case when PatPay.PatientID IS NULL
            then ' '
            else Date_format( PatPay.LastPaymentDate, '%d-%m-%Y') end lastpaymentdate
    FROM 
        patient p
            LEFT JOIN
            ( select 
                    i.patientID,
                    sum( i.ammount ) justSumOfAmount,
                    sum( i.ammount * ( discount / 100 )) as discountedAmounts
                from
                    invoice i
                where
                    i.invoicedNumber > 0
                group by
                    i.patientID
                order by
                    i.patientid ) PatInv
                on p.patientid = patInv.patientID
            LEFT JOIN
            ( SELECT
                    pay.patientID, 
                    Sum(pay.ammount) paidAmounts,
                    max( pay.paymentDate ) LastPaymentDate
                FROM
                    payment pay
                group by
                    pay.patientID 
                order by
                    pay.patientid ) PatPay
                on p.patientID = patPay.PatientID

J'ai publié cette requête sur SQL Fiddle De plus, en regardant vos tables, vos factures et vos tables de paiement DEVRAIT CHACUN avoir un index sur l'ID patient pour aider à optimiser la requête . Je ne sais pas s'il s'agissait d'un exemple de surveillance de poste de votre sql-fiddle vs production, mais cela aussi aurait un impact sur les performances.

L'option SQLFiddle que j'ai prend 5 ms par rapport à vos 2-3 ms, mais cela est uniquement pour les quelques enregistrements fournis. Je parierais que contre plus de 1000 patients et 1000 de transactions dans chaque facture et table de paiement, cette option de requête sera plus rapide que les requêtes corrélées.

Considérez votre requête comme ceci. J'ai 1000 patients. Interrogez le tableau des factures 1 000 fois, interrogez le tableau des paiements 2 000 fois (1 000 pour la somme des paiements, 1 000 fois pour la date la plus récente par patient).

Ma requête - Faites une pré-requête sur le tableau des factures une fois et résumer 1 enregistrement par patient. Demandez une fois le tableau de paiement et récapitulez 1 enregistrement par patient. Joignez les patients à ces deux sous-tableaux directement par ID.

Les performances médiocres de tout système RDBM sont dues à une mauvaise conception. Dans votre SQL Fiddle, vous enregistrez des nombres dans le champ varchar . Votre moteur de table actuel est MyISAM qui ne prend pas en charge les relations !? Pas de relations => pas d'index => pas de recherches rapides

Afin d'améliorer les performances, je vous suggère de changer la conception de votre table. Le tableau des factures peut avoir les modifications suivantes. Changez le moteur en InnoDB et

ALTER TABLE `invoice` ENGINE = Innodb;

ALTER TABLE `invoice` 
CHANGE COLUMN `patientid` `patientid` INT(12) UNSIGNED NOT NULL ,
CHANGE COLUMN `ammount` `ammount` DECIMAL(14,2) NOT NULL ,
CHANGE COLUMN `discount` `discount` DECIMAL(3,2) NULL DEFAULT '0' ,
ADD INDEX `fk_invoice_patient_idx` (`patientid` ASC);
ALTER TABLE `invoice` 
ADD CONSTRAINT `fk_invoice_patient`
  FOREIGN KEY (`patientid`)
  REFERENCES `test`.`patient` (`patientid`)
  ON DELETE RESTRICT
  ON UPDATE CASCADE;

qui a instantanément amélioré toutes les recherches entre le patient et le tableau de facturation. Apportez les mêmes modifications à votre tableau de paiement, puis comparez vos résultats.

Après les modifications ci-dessus, vous pouvez créer des vues pour les paiements et les factures ou des sous-requêtes comme les autres mentionnées pour accélérer davantage.

p>